From owner-svn-src-all@FreeBSD.ORG Fri Feb 4 02:28:28 2011 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F24A5106566B; Fri, 4 Feb 2011 02:28:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 872C08FC14; Fri, 4 Feb 2011 02:28:27 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p142SMng030705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Feb 2011 13:28:25 +1100 Date: Fri, 4 Feb 2011 13:28:22 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: mdf@FreeBSD.org In-Reply-To: Message-ID: <20110204125820.Q935@besplex.bde.org> References: <201102021635.p12GZA94015170@svn.freebsd.org> <201102030750.07076.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Juli Mallett , svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, John Baldwin 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 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 02:28:28 -0000 On Thu, 3 Feb 2011 mdf@FreeBSD.org wrote: > Bruce correctly points out that the code doesn't work like I expect > with PREEMPTION, which most people will be running. Not just PREEMPTION, but with almost any non-fast^Wfiltered interrupt activity. > I'm thinking of adding a new per-thread field to record the last ticks > value that a voluntary mi_switch() was done, so that there's a > standard way of checking if a thread is being a hog; this will work > for both PREEMPTION and !PREEMPTION, and would be appropriate for the > places that previously used a counter. (This would require > uio_yield() to be SW_VOL, but I can't see why it's not a voluntary > context switch anyways). I don't like using a ticks value for this at all. It gives complexities and doing the scheduler's work for it. If you don't count involuntary context switches, then the ticks spent by involuntarily-switch-to threads will be counted against the hog thread. And switches back from these threads are probably voluntary (this is the case for ithreads), so you would need complexities to not reset the last ticks values for some voluntary context switches too. A perfectly fair way to keep track of hoggishness might be to monitor the thread's runtime and yield if this is too large a percentage of the real time, but this might be complex and is doing the scheduler's work for it (better than the scheduler does -- schedulers still use ticks, but the runtime is much more accurate). OTOH, yielding on every tick might work well. This is equivalent to reducing hogticks to 1 and doesn't need an externally maintained last- tick value. Just do an atomic cmpset of `ticks' with a previous value and yield if it changed. This could probably be used for increments of larger than 1 too. But I now remember that the hogticks checks are intentionally not done like this, so that they can be as small and efficient as possible and not need local state or a function call. I must have expected them to be used more. The reason to consider yielding on every tick is that 2 quanta (200 mS) isn't as long as it was when it was first used for hogticks. Back then, memory speeds were maybe 50 MB/S at best and you could reach hogticks limit simply by reading a few MB from /dev/zero. > I'm happy to rename the functions (perhaps just yield_foo() rather > than foo_yield()?) and stop using uio_yield as the base name since > it's not a uio function. I wanted to keep the uio_yield symbol to > preserve the KBI/KPI. Errors should not be preserved. Bruce