Date: Thu, 10 Apr 2003 11:03:31 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: RE: cvs commit: src/sys/ddb db_ps.c src/sys/i386/i386 genassym.c kern_thread.c sched_4bsd.c sched_ule.c subr_smp.c subr_witness.c src/sys/sys proc.h Message-ID: <Pine.BSF.4.21.0304101042120.55025-100000@InterJet.elischer.org> In-Reply-To: <XFMail.20030410134111.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Apr 2003, John Baldwin wrote: > > On 10-Apr-2003 Julian Elischer wrote: > > julian 2003/04/10 10:35:45 PDT > > > > FreeBSD src repository > > > > Modified files: > > sys/ddb db_ps.c > > sys/i386/i386 genassym.c > > sys/kern init_main.c kern_fork.c kern_mutex.c > > kern_proc.c kern_thread.c sched_4bsd.c > > sched_ule.c subr_smp.c subr_witness.c > > sys/sys proc.h > > Log: > > Move the _oncpu entry from the KSE to the thread. > > The entry in the KSE still exists but it's purpose will change a bit > > when we add the ability to lock a KSE to a cpu. > > Why not add a ke_pincpu to hold the bound CPU? Since KSE's are in > theory a kind of virtual CPU abstraction the thread really seems to > be the wrong place for this information. That's what I said (or at least meant to)(except that I haven't renamed the old entry in the ke yet (I haven't decided on a name)). The entry in the thread only says where it is running NOW. All of the users of the "what cpu are you on now?" value can use it better if it's in the thread. In many cases this was the only reason for the code in question to even know that there was such a thing as a KSE, where they already have a thread pointer. This is part of my push to make the KSE itself invisible to parts of the CPU that don't need toknow about it.. Much of the kernel needs to know only about threads. A slightly smaller but largely different part needs to know about processes. A much smaller part needs to know about KSEGRPS, Almost nothing outside the scheduler needs to know about KSEs. Since KSEs themselves are really a scheduler abstraction (i.e. a fairness tool mostly) since David created the upcall structure, I'm trying to limit their use to within the scheduler. This gives us a possibility of creating a thread scheduler that uses a completely different way of enforcing fairness, and in fact my first test of whether I have succeeded will be to create an "unfair" scheduler, that has no KSEs and schedules the threads directly. It's un unfortunate fact that when we allocated names to the various structures on teh whiteboard in 1999 we called the entry that was put on the run-queue to enforce fairness the KSE, and that name came to symbolise the entire effort, because it's the structure most likely to be found un-needed if someone writes a different thread scheduler. This leaves us in the odd situation of having "KSE" threading possibly without KSEs. Unfortunatly the names have been "organically grown" during discussions a couple of years ago and "stuck". I've been pushing for a long time now about renaming things but discussion has always ended up with "yes, but we've more important things to fix right now". :-) I might add that the upcall structure may end up being the main vehicle for cpu binding rather than the KSE. Obviously the scheduler is involved in that so the KSE may also be involved, as it's visible. > > -- > > John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0304101042120.55025-100000>