Date: Mon, 07 Jul 2003 18:42:03 +0300 From: Petri Helenius <pete@he.iki.fi> To: deischen@freebsd.org Cc: freebsd-threads@freebsd.org Subject: Re: thread scheduling priority Message-ID: <3F0994CB.6070403@he.iki.fi> In-Reply-To: <Pine.GSO.4.10.10307071040240.10341-100000@pcnet5.pcnet.com> References: <Pine.GSO.4.10.10307071040240.10341-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: >Mutexes are implemented using direct handoff (I think that's the >term). Once a mutex is released, it is given to the next thread >that is waiting on it and that thread is then marked runnable. >Idle KSEs are suppose to be woken whenever there are runnable >threads. > > So when the main thread unlocks the mutex there are two runnable threads, which one keeps running? >For now, just see if things work better with 1 CPU defined. >If not, then all this talk about multiple KSEs isn't your >problem; it is something else. > > It definetly runs a lot better, however not as good as I would expect if the running thread would be switched to the higher scheduling priority thread immediately on the mutex release. Should that happen or does it wait until the other thread hits a blocking condition ? > > >>I assume the "correct" setting for virtual_cpu in my case would be 2 ? >> >> > >It shouldn't matter. Libkse should do the right thing regardless >of how many CPUs you have. In your case, there may be extra >overhead with having only 2 threads. Both idling of a KSE and >waking a KSE are system calls, whereas normal thread switches >within the same KSE are not. Depending on how often your >threads run and block, running those 2 threads on 2 KSEs may >not be as efficient as running them with only 1 KSE. > > Unfortunately the code has not been designed with threads in mind initially so there is quite a large table protected with a mutex and the plan is to lock either each element or block of elements separately and have a significantly larger number of "worker threads" and as far as I understand there is not really an issue of having, say 65536 mutexes, as long as I keep the threads from running into locking ordering issues. (no performance issues, etc.) Dual-CPU is not really the target platform anyway, more like 4-8 way things where the benefits greatly outweigh the penalties. >The way to set the number of KSEs allocated to run scope >process threads is to use pthread_setconcurrency(). This >currently can't be used to reduce the number of KSEs, but >it is on our TODO list. Also, there is currently no way >to tell libkse not to automatically create as many KSEs >as defined by kern.threads.virtual_cpus. Perhaps we'll >add an environment variable to do this. > > It would probably be useful if the default for kern.threads.virtual_cpus took into account machdep.hlt_logical_cpus setting. (halving the default value if hlt_logical_cpus == 1, but as you say, it's really an optimization) And yes, my SMP box has machdep.cpu_idle_hlt: 0 although it sucks up about 100W more power that way and is about 20'F hotter in the chassis than with the idle_hlt. >Perhaps we also need a better method of auto-tuning the >number of KSEs. If KSEs are not utilizing much of their >quantum and there is a lot of idling and waking of them, >then we're better off with less of them. > > > I like the thread development a lot, using threads on FreeBSD was a futile thing only a short time ago, now it actually makes a lot of things easier to develop leading to more efficient applications. Pete
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F0994CB.6070403>