Date: Fri, 4 Feb 2011 00:10:33 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Juli Mallett <jmallett@freebsd.org> Cc: svn-src-head@freebsd.org, Matthew D Fleming <mdf@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r218195 - in head/sys: amd64/amd64 arm/arm i386/i386 ia64/ia64 kern mips/mips powerpc/powerpc sparc64/sparc64 sun4v/sun4v sys ufs/ffs Message-ID: <20110203235212.S2089@besplex.bde.org> In-Reply-To: <AANLkTi=5jDcYAfuoWtgDTUk__JJK222efBd9YgPq6hsf@mail.gmail.com> References: <201102021635.p12GZA94015170@svn.freebsd.org> <AANLkTi=5jDcYAfuoWtgDTUk__JJK222efBd9YgPq6hsf@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1747581021-1296738633=:2089 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 2 Feb 2011, Juli Mallett wrote: > On Wed, Feb 2, 2011 at 08:35, Matthew D Fleming <mdf@freebsd.org> wrote: >> Author: mdf >> Date: Wed Feb =A02 16:35:10 2011 >> New Revision: 218195 >> URL: http://svn.freebsd.org/changeset/base/218195 >> >> Log: >> =A0Put the general logic for being a CPU hog into a new function >> =A0should_yield(). =A0Use this in various places. =A0Encapsulate the com= mon >> =A0case of check-and-yield into a new function maybe_yield(). >> >> =A0Change several checks for a magic number of iterations to use >> =A0should_yield() instead. Grr, hard \xa0. > First off, I admittedly don't know or care very much about this area, > but this commit stood out to me and I had a few minor concerns. I sent a long private mail saying how it is quite broken. The hogticks hasn't worked for 10.4 years, since switchtime is reset on every context switch and there are lots of context switches for ithreads). Thus should_yield() almost always returns false, and the old code that used its logic was mostly dead. The old code that didn't use its logic worked, but now mostly doesn't. Also, preemption makes the non-preemptive yielding mostly unnecessary. When preemption occurs, it doesn't do the right thing in cases where it is necessary to drop all locks, while manual yielding does. But preemption certainly resets switchtime, so if is happening then sched_yield() returns false always instead of only almost always. (Almost always is when the context switch rate is less than 5 Hz. Non-fast interrups at more than 5 Hz normally prevent this.) > I'm slightly uncomfortable with the flat namespace here. It isn't > obvious from the names that maybe_yield() and should_yield() relate > only to uio_yield() and not other types of yielding (from DELAY() to > cpu_idle() to sched_yield().) The other problematic element here is I noted many namespace problems too, starting with my static uio_yield() already being exported for abuse by non-uio things. > Linuxy. I think names like uio_should_yield() and uio_maybe_yield() > wouldn't have nearly as much of a problem, since the context of the > question of "should" is isolated to uio operations rather than, say, > whether the scheduler would *like* for us, as the running thread, to > yield, or other considerations that may be more general. But this has nothing to do with uio. The uio case has been most perfectly broken for 10.4 years, since the uio_yield() calls for actual uio things are the main places that use the should_yield() condition. Non-uio places mostly did an unconditional uio_yield(), and this worked. I think uio also doesn't hold any locks, for the same reason that copyin()/out() don't (it might fault and have to sleep for a long time). Thus preemption works right for the uio case, and its perfect brokenness 10.4 years ago turned into mostly just dead code when the kernel became preemptible. The breakage is perfect in bdeBSD, since it uses ithreads for clock interrupts. Thus switchticks is guaranteed to be reset by the same interrupts that advance `ticks', and so (ticks - switchticks) is either 0 or 1 (mostly 1?). Bruce --0-1747581021-1296738633=:2089--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110203235212.S2089>