Date: Wed, 2 Feb 2011 23:47:20 -0800 From: Juli Mallett <jmallett@FreeBSD.org> To: Matthew D Fleming <mdf@freebsd.org> Cc: svn-src-head@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: <AANLkTi=5jDcYAfuoWtgDTUk__JJK222efBd9YgPq6hsf@mail.gmail.com> In-Reply-To: <201102021635.p12GZA94015170@svn.freebsd.org> References: <201102021635.p12GZA94015170@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 comm= on > =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. 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'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 that "maybe_yield" and "should_yield" could quite reasonably be variables or functions in existing code in the kernel, and although we don't try to protect against changes that could cause such collisions, we shouldn't do them gratuitously, and there's even something that seems aesthetically off about these; they seem...informal, even 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. Thanks, Juli.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=5jDcYAfuoWtgDTUk__JJK222efBd9YgPq6hsf>