The message quoted below is from a MandrakeSoft co-worker and friend, in
a thread discussing APM's kernel thread, and how the idle function uses
CPU time. This thread was in response to yet another Bugzilla bug
report about kapm-idled using CPU time.
Several months ago, kapmd was renamed to kapm-idled in an attempt to
signal users that it was a special process, and that its CPU time wasn't
"real CPU time." This hasn't silenced the bug reports and confusion.
Is there some way to hack the scheduler statistics so that idle
processes are special cases, which do not accumulate CPU time nor
contribute to the load average?
I agree that it's not pretty to special case idle function process(es),
but those idle functions in turn are causing an incorrect picture of the
system state to be presented to userland.
Jeff
--
Jeff Garzik | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft | and a smooth road all the way to your door.
Guillaume Cottenceau wrote:
> On the other hand, you'll agree Jeff that it needs some fixing: it's
> fucking up many statistics such as load average and instant cpu usage, and
> is very confusing for people..
>
> On another side, what I don't understand is that its cpu usage is not
> constant, which makes people things it's sort of a bug: for example my
> machine is up 1 day, 18:33 with 2.4.2-15mdk, kapm-ideld is reported to
> have consumed 1355m, but currently it's staying at 0.0% of cpu. Sometimes
> it gets bigger, sometimes it gets lower. Rather confusing.
[email protected] (Jeff Garzik) writes:
> Is there some way to hack the scheduler statistics so that idle
> processes are special cases, which do not accumulate CPU time nor
> contribute to the load average?
I wondered about getting kapm-idled to take the CPU time allocated to
itself, and reallocate to the idle task. Something like the following
at a strategic point inside the apm loop.
unsigned long user, system;
user = current->times.tms_utime;
system = current->times.tms_stime;
current->times.tms_utime = current->times.tms_stime = 0;
idle->times.tms_utime += user;
idle->times.tms_stime += system;
I haven't looked to see what point would be a good idea, and investigated
what locks need to be held. I've also just peeked at the 2.4 code,
and seen "current->per_cpu_utime[cpu]" -- does this need handling?
Is it visible to user space?
If you looked closely, you might see the CPU time falling for kapm-idled,
but generally you would see it allocated to the idle task, and not
kapm-idled.
> I agree that it's not pretty to special case idle function process(es),
> but those idle functions in turn are causing an incorrect picture of the
> system state to be presented to userland.
At least with this scheme, the special casing is inside the kapm specific
code, and not within the general timer handling.
Of course, this is no more than an idea. I haven't got as far as
running 2.4 on my only APM machine (486 Thinkpad), let alone trying out
this scheme.
--
`O O' | [email protected]
// ^ \\ | http://www.pyrites.org.uk/
On Sun, 18 Mar 2001, Jeff Garzik wrote:
> Is there some way to hack the scheduler statistics so that idle
> processes are special cases, which do not accumulate CPU time nor
> contribute to the load average?
It's trivial. I remember seeing a patch that does exactly this
on linux-kernel, probably around the time kapmd was renamed.
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
> Several months ago, kapmd was renamed to kapm-idled in an attempt to
> signal users that it was a special process, and that its CPU time wasn't
> "real CPU time." This hasn't silenced the bug reports and confusion.
And instrumenting the number of calls to the apm idle function I am
not convinced that apm idle is working for all laptops as other people have
claimed.