Re: P_NOLOAD + ULE = high load averages

On Tue, 27 Apr 2004, Nikos Ntarmos wrote:

> On Thu, Apr 22, 2004 at 05:24:30PM -0400, Robert Watson wrote:
> > I chatted with Jeff briefly about this change: he pointed out that
> > this change may not work well if the flag can change at run-time,
> > and it looks like (from a grep) that it may be.  It looks like it
> > only changes because it isn't set in kthread_create(), since it
> > appears to be a static thread property once the thread is off
> > running, so perhaps we just need to make sure it's set in
> > kthread_create and doesn't change later.
>
> Looking at the sources I found out that P_NOLOAD is dropped by
> kthread_create() only because fork1() selectively copies P_* flags
> from the father to the child process. I'm not sure whether that's
> right or wrong, but FWIW it seems ok to me. After all, grep'ing my way
> through the source tree, I found only three cases of P_NOLOAD'ed
> processes: "idle", "pagezero", and the "clock" swi. AFAIK none of
> these will ever fork a child, so preservation of P_NOLOAD seems like a
> non-issue to me. Plus, the proposed fix only affects the calculation
> of the load averages, and does so in the right direction imo. Anyway,
> it seems like the change was committed, so could someone close
> kern/65857?

It would be a bug for any of these threads to fork a child.

P_NOLOAD doesn't work quite right, but something has to be done for
these these 3 threads to avoid always counting them in the load.  The
flag works right for the idle p because the idle thread does nothing.
The other threads do useful work, so at least their runtime contribution
to the load should be counted.

For the pagezero thread, not setting the flag works almost right since
the thread spends most of its time sleeping on pgzero.  However, when
the system runs short on zero pages, pagezero becomes runnable but
might never run because the system is doing other higher priority work.
It is traditionally not counted in the load average and the flag keeps
it so.  Userland idle priority threads have similar behaviour, but are
not treated specially so they just contribute to the load.

For the clock swi, the problem is that the thread is always running
when it samples the count of running and runnable threads, so something
must be done to stop it always counting itself.  Setting the flag
causes it to never count itself, so itse contribution to the load
is never counted.  Another problem is that the clock swi can never
run while higher priority threads are running or runnable.  Most
kernel threads have higher priority, so their contribution to the
load is never counted.

Bruce