Date: Fri, 7 Mar 2008 11:19:51 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: arch@freebsd.org Subject: Re: Getting rid of the static msleep priority boost Message-ID: <Pine.GSO.4.64.0803071114100.1950@sea.ntplx.net> In-Reply-To: <20080307020626.G920@desktop> References: <20080307020626.G920@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 7 Mar 2008, Jeff Roberson wrote: > Hello, > > I've been studying some problems with recent scheduler improvements that help > a lot on some workloads and hurt on others. I've tracked the problem down to > static priority boosts handed out by msleep/cv_broadcastpri. The basic > problem is that a user thread will be woken with a kernel priority thus > allowing it to preempt a thread running on any processor with a lesser > priority. The lesser priority thread may in fact hold some resource that the > higher priority thread requires. Thus we context switch several times and > perhaps go through priority propagation as well. > > I have verified that disabling these static priority boosts entirely fixes > the performance problem I've run into on at least one workload. There are > probably others that it helps and hopefully we can discover that. > > I'd like to know if anyone has a strong preference to keep this feature. It > is likely that it helps in some interactive situations. I'm not sure how > much however. I propose that we make a sysctl that disables it and turn it > off by default. If we see complaints on current@ we can suggest that they > toggle the sysctl to see if it alleviates problems. > > Based on feedback from that experiment and some testing we can then choose a > few options: > > 1) Disable the static boosts entirely. Leave kernel priorities for kernel > threads and priority propagation. Most other kernels do this. Would make my > life in ULE much easier as well. > > 2) Leave the support for static boosts but remove it from all but a few key > locations. Leaving it in the api would give some flexibility but might > confuse developers. > > 3) Leave things as they are. undesirable. > > I'm leaning towards #2 based on the information I have presently. This is > almost a significant change to historic BSD behavior so we might want to > tread lightly. I'm not sure if any of the above remove the priority from the API, but it would be nice to get rid of msleep totally and replace it with an equivalent cv_wait(). I read jhb's comments, so perhaps some form of msleep() or equivalent that gives hints for the priority could be kept, but removed from all other places that don't need it. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0803071114100.1950>