Date: Fri, 19 Jul 2002 16:18:40 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Luigi Rizzo <rizzo@icir.org> Cc: current@freebsd.org Subject: Re: Relations between KSE, KSEG and NCPU Message-ID: <Pine.BSF.4.21.0207191555560.91009-100000@InterJet.elischer.org> In-Reply-To: <20020719155202.D37800@iguana.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 19 Jul 2002, Luigi Rizzo wrote: > Hi, > I am trying to figure out what are the relations between > KSE's, KSEG and NCPU -- from the description in kern_switch.c > and in sys/proc.h I am not totally clear if: > > 1) a KSEG can have more KSE than NCPU; At this time of course you are limitted to one KSE :-) In the near course, I don't think there will be algorythmic reasons to not allow more than N KSEs, (thugh that may become true) but having more than N KSEs is pretty much a waste of time as all KSEs in a group are equivalent, so they are interchangeable.. this means that if you have N CPUS and N+1 KSEs the KSE that is running is stealing the slot of one of it's own siblings.... so what is the point? It might allow a KSEG to compete "unfairly" against other KSEGs however so for that reason I plan to 'artificially' limit NKSE to NCPU. > 2) a KSEG can have multiple KSE's running on different CPUS; yes (well, when we allow multiple KSEs) there is nothing stopping KSEs from running on different processors, in fact it is hoped that eventually each KSE will be basically 'soft wired' to a processor, to give a scheduler 'slot reservation' on each cpu for the running of the threads in that KSEGRP. How this is achieved will rely somewhat on the scheduler implemented, which is why I want the schedulers to be 'pluggable' so that people can experiment with this.. > > Also I do not follow this comment in sys/proc.h: > > * Kernel-scheduled entity group (KSEG). The scheduler considers each > KSEG to > * be an indivisible unit from a time-sharing perspective, though each > KSEG may > * contain multiple KSEs. > > Does it mean that once the scheduler picks a KSEG it will try > to place as many KSE's as it can on the available CPUs, rather > than sharing the latter between KSEG's with ready threads ? This comment is 1/ out dated 2/ confusing. The word 'indivisible' is definitly wrong. 3/ heavily dependent on who writes the scheduler :-) I really cannot think of a good way to say what is correct however. The KSEG has the scheduling parameters and statistics for the group. In a process with one KSEG, these could be considered to be the process-wide scheduling stats and parameters (nice etc.), except that we allow >1 KSEG (eventually) so that different parameters can be given to differnt KSEGS allowing different threads to have different scheduling behaviour. The current schedular does not pick KSEGs (though some other 'gang scheduler' might do so). At this time each CPU picks a KSE and runs it. The KSE in turn has selected a thread from that KSEG. (or the thread selected it..) When the thread finishes. there is the possibilty (not yet implemented) that the KSE looks for other such threads to run before giving up the processor. If different KSEs are running at once on differnt processors they would probably do well to try select threads with 'some affinity' to that processor but this too is not yet implemented (well you can only have one KSE at the moment).. My aim it to provide enough data abstraction to allow people to write their own schedulers and try aout all sorts of affinities and grouping strategies. By grouping the 4 structures in different ways it is possible to simulate almost all the scheduling structures I have seen in the literature. > > thanks > luigi > ----------------------------------+----------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) > http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 > Phone: (510) 666 2927 > ----------------------------------+----------------------------------------- > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0207191555560.91009-100000>