Date: Sun, 25 Nov 2001 21:26:51 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Peter Wemm <peter@wemm.org> Cc: Luigi Rizzo <rizzo@aciri.org>, Mike Smith <msmith@FreeBSD.ORG>, John Baldwin <jhb@FreeBSD.ORG>, <current@FreeBSD.ORG> Subject: Re: where is the idle_loop in current ? Message-ID: <20011125195537.X5075-100000@delplex.bde.org> In-Reply-To: <20011124023142.9BB70380D@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011125195537.X5075-100000>