> Date: Sat, 19 Mar 2016 09:06:26 +0100 > From: Alexandre Ratchov <a...@caoua.org> > > On Fri, Mar 18, 2016 at 08:00:35PM +0100, Mark Kettenis wrote: > > > From: Bob Beck <b...@openbsd.org> > > > Date: Fri, 18 Mar 2016 09:20:35 -0600 > > > > > > this is cool .. but > > > > > > I would be interested in someone comparing server workloads, as > > > opposed to interactive GUI response, using this. > > > > > > I wouldn't be surprised that inspiriation from BFS would produce > > > better interactive response, my bigger concern would be does this > > > adversely impact how we deal with non-interactive workloads. > > > > One other important case to test is network packet forwarding. Some > > of our network stack is now running inside a kernel thread. And any > > changes in the scheduling behaviour have the potential of having a > > significant impact there. > > > > Another interesting case is the page zeroing thread. It relies on > > priority-based scheduling to make sure it only runs if we have nothing > > better to do. > > > > So I'm skeptical about this BFS scheduler. Don't get me wrong; I do > > think the scheduler needs attention. But I'm not sure a scheduler > > designed for interactive desktop use is the best option for OpenBSD. > > IMHO current OpenBSD scheduler *is* designed for interactive > programs too, that's why I keep using OpenBSD for real-time audio > and didn't switch to Linux or OS X or whatever. > > The browsers problems seem caused by the way pthreads behave; > browsers appear to spin. With the proposed scheduler they spin > less. But the real question is why they spin at all?
If we still hit the remaining spinlocks in libpthread, we should probably replace the ones we hit with mutexes like I did for malloc.
