From owner-freebsd-current Sun Nov 25 2:28:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9BFAD37B405; Sun, 25 Nov 2001 02:28:19 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA10230; Sun, 25 Nov 2001 21:28:12 +1100 Date: Sun, 25 Nov 2001 21:26:51 +1100 (EST) From: Bruce Evans X-X-Sender: To: Peter Wemm Cc: Luigi Rizzo , Mike Smith , John Baldwin , Subject: Re: where is the idle_loop in current ? In-Reply-To: <20011124023142.9BB70380D@overcee.netplex.com.au> Message-ID: <20011125195537.X5075-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 23 Nov 2001, Peter Wemm wrote: > Luigi Rizzo wrote: > > My understanding is that idle_loop threads _need_ to give up the cpu > > because they are special: they must never be in a run queue, and the > > scheduler knows about them (as a matter of fact, I cannot see where > > in kern/kern_idle.c a priority is associated to these threads). > > No. In -current, the idle procs ***MUST***NOT*** do anything. I.e., the unique idle process for each cpu. A comment in idle_proc() still says otherwise: > for (;;) { > mtx_assert(&Giant, MA_NOTOWNED); > > #ifdef DIAGNOSTIC > count = 0; > > while (count >= 0 && procrunnable() == 0) { > #else > while (procrunnable() == 0) { > #endif > /* > * This is a good place to put things to be done in > * the background, including sanity checks. > */ This is actually a BAD place for doing anything. > > If you want to do something at idle, you have to have an idle > process/thread/whatever. This is how vm_zeroidle works. It is > a process that is on the run queue. vm_zeroidle is a good example of how not to do things. Its watermark stuff makes its idleness not very important. My version of it wakes up the pageout daemon a lot (but subject to a watermark) to maintain a sufficient supply of pages of each color, and I've never noticed problems (from this) due to the pageout daemon having much higher priority. It's the check for whether there is a page worth zeroing (and whether there is a shortage of pages of some color in my version) that should be done at idle priority, not the actual zeroing/freeing. Once committed to zeroing/freeing, it's probably a mistake to d it at a low priority, since getting switched from and back to work that must be done won't help. Things have regressed a bit relative to RELENG_4. The check for pages to zero used to be done lazily. Now it is done in the main path of vm, by calling vm_page_zero_idle_wakeup() from vm_page_free(). So we are now using an idle process for precisely the parts of idly zeroing pages that don't need to be done idly. However, the watermark stuff limits the damage. > > But I really do not follow the "safer design" reasoning for > > vm_zeroidle. It would be much safer not to depend on it to cooperate > > in the scheduling and be subject to to the regular scheduling policy > > (i.e. preempt when someone with higher priority becomes ready, > > or when its quantum is over). > > Thats the problem.. We do *not* have preemption in -current right now. > If it takes 10 seconds to zero all memory, the system will freeze for 10 > seconds while vm_zeroidle runs, even if there is a higher priority process > on the runqueue. The watermark stuff limits the damage. It won't actually zero all memory since to high watermark is 4/5*cnt.v_free_count. cnt.v_free_count must not be very large or the pageout daemon might cause long freezes too. The pageout daemon will give up control if it writes to swap; this sort of corresponds to the pagezero deamon giving up control after every idlezero_maxrun pages (default 16). Anyway, I think luigi wants the non-process benefits of hacking on the old idle loop. Sorry, the only way to get these seems to be to upgrade to RELENG_4. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message