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);
>               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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to