Date: Mon, 20 Nov 2000 23:41:11 -0800 From: Julian Elischer <julian@elischer.org> To: Terry Lambert <tlambert@primenet.com> Cc: Scott Hess <scott@avantgo.com>, jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments Message-ID: <3A1A2717.3270D40F@elischer.org> References: <200011202156.OAA02067@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
>
> > I have seen the notion of limiting KSE's to the number of CPUs mentioned a
> > number of times on the arch and smp lists. This is presumably done to
> > maximize performance of CPU-bound and network-I/O-bound programs.
>
> A KSE is a "reservation for quantum". It is effectively a quantum
> holder. The quantum can be spread against multiple threads in user
> space. Except on multiple CPUs, which would permit multiple KSEs,
> all CPU utilization is serialized through the scheduler anyway.
>
> What a KSE buys you is thread group locality for context switcthes,
> which is something that is computationally difficult to achieve
> satisfactorily in a Linux or SVR4 approach to kernel threading,
> since it can quickly lead to starvation deadlock, where a threaded
> process gets affinity preference for its ready-to-run threads in
> the scheduler, thus starving everything else in the scheduler queue
> which is not the threaded process.
>
> In other words, it's incredibly hard to achieve affinity after
> you have broken the quantum-process accounting connection. KSEs
> preserve this connection.
>
> This typically means that, if you are attempting to use multiple
> threads to unfairly compete for quantum, you will have to follow
> the scheduler priority rules instead (many threads programmers
> use threads in an attempt to subvert the scheduler policy without
> resorting to increased priviledges; this is wrong).
>
> So your examples are all workable, merely by providing multiple
> user space threads.
>
> > On Mon, 20 Nov 2000, Julian Elischer wrote:
> > > A KSEG can only have as a maximum N KSEs associated with it, where N is
> > > the number of processors, (unless artificially reduced by a lower
> > > concurency declaration). (you said this but only indirectly). In
> > > general, KSEs are each assigned to a processor. They do not in general
> > > move between processors unless some explicit adjustment is being
> > > made(*), and as a general rule, two KSEs will not be assigned to the
> > > same processor. (in some transitional moments this may be allowed to
> > > briefly happen) This in general if you run a KSEC on the same KSE it was
> > > run on last time, you should be on the same processor,
> > > (and get any affinity advantages that might exist).
>
> I really, really disagree with Julian's statement about not
> assigning multiple KSEs to the same processor. There are
> perfectly valid loading reasons (e.g. two KSEs that each take
> 30% of the CPU, cooperating, with one CPU with a process that
> takse 90% of the CPU, while the other CPU is only at 60%
> utilization, etc.).
NOT within the same KSEG...
don't forget that to some extent the amount of CPU each KSE
will get will depend on how much work it has.. hopefully the
KSEs with 30% loads will have done 'yields'.
>
> There is also the PTHREAD_SCOPE_SYSTEM scheduling; one can
> easily conceive of a multithreading application, where one thread
> in the total list of threads needs to run with a real time
> priority to insure rapid interacative response, with metered
> intervals. One example would be a DVD player, where the
> rendering needs to occur at fixed intervals with no latency,
> whereas the fuffer-refill from the DVDROM, and the control
> functons for the program, overall, can run in normal priority
> threads.
This is ONE KSE PER CPU PER KSEG......
you can have several KSE's competing for a processor.
put them in differnt KSEGs.
>
> So I think there is a good argument for needing to support in
> the kernel the idea of multiple KSEs on a single processor; I
> understand Julian's anxiety about what this could do to the
> complexity of the sleep queues, but with respect to everyone,
> if the task's too complex, then stay out of the kernel (it's
> not too complex for Julian, it's just I don't think that the
> kernel should have to be written on the computer science
> equivalent of a 6th grade reading leveli: if it can't be
> understood by everyone, too bad: most people couldn't tell
> you how the ignition system in their car works, either).
you misunderstood my comment
>
> Terry Lambert
> terry@lambert.org
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000
---> X_.---._/ presently in: Budapest
v
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A1A2717.3270D40F>