I've recently begun testing my laptop on the latest 2.4.0-test12-pre[78]
kernels. When freshly booted and nothing producing a load on the system,
top reports a process called 'kapm-idled' consuming between 60% an 85%
of CPU cycles. If I induce a load on the machine (by recompiling kernel
modules, for example), this process slowly loses priotity and stops
consuming cycles. Once the compilation is complete, it climbs back up to
the top of the stack again. Here are top snapshots taken at about 90
second intervals:
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
3 root 20 0 0 0 0 SW 0 81.7 0.0 1:14 kapm-idled
3 root 20 0 0 0 0 SW 0 76.8 0.0 1:41 kapm-idled
* 3 root 9 0 0 0 0 SW 0 0.0 0.0 3:09 kapm-idled
3 root 14 0 0 0 0 SW 0 60.5 0.0 3:39 kapm-idled
3 root 20 0 0 0 0 SW 0 85.7 0.0 5:15 kapm-idled
* during re-compilation of kernel modules, kapm-idled was de-prioritized
and took up no CPU cycles. after the compilation completed, the task
priority increased until it was again consuming hi percentages.
I've consistently re-produced this on my Dell Latitude CS laptop. I'm
wondering if this will reduce battery life since the CPU is constantly
being loaded instead of properly idled.
Stewart
On Mon, 11 Dec 2000 [email protected] hissed:
> I've recently begun testing my laptop on the latest 2.4.0-test12-pre[78]
> kernels. When freshly booted and nothing producing a load on the system,
> top reports a process called 'kapm-idled' consuming between 60% an 85%
> of CPU cycles. [...]
its supposed to do this - its taking up the idle thread. its not actually
using those cpu cycles, dont worry.
yes, i agree -- its cpu usage shouldnt be shown as normal but integrated
under the idle thread.
--
Robert M. Love
[email protected]
[email protected]
On Mon, 11 Dec 2000 [email protected] wrote:
[snip whine]
> I've consistently re-produced this on my Dell Latitude CS laptop. I'm
> wondering if this will reduce battery life since the CPU is constantly
> being loaded instead of properly idled.
What do you suppose the 'idled' in 'kapm-idled' stands for?
Rik
--
Hollywood goes for world dumbination,
Trailer at 11.
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
[email protected] (Rik van Riel) writes:
> On Mon, 11 Dec 2000 [email protected] wrote:
> [snip whine]
>
> > I've consistently re-produced this on my Dell Latitude CS laptop. I'm
> > wondering if this will reduce battery life since the CPU is constantly
> > being loaded instead of properly idled.
>
> What do you suppose the 'idled' in 'kapm-idled' stands for?
We know it was an attempt to stop people complaining about the fact that
"kapm" was hogging the CPU. Looks like it doesn't work.
At the time, I had a look at the kernel source, and came to the conclusion
that there was no easy way for the cpu accounting in "do_process_times()"
to automatically assign ticks from a particular process to the idle
process.
However, would it be possible for apm_cpu_idle() to periodically assign
the values for per_cpu_*time for the kernel thread to the idle process?
This isn't a performance critical part of the kernel, and would lead to
less false reports (as above).
--
`O O' | [email protected]
// ^ \\ | http://www.pyrites.org.uk/
very helpful.
Technical merits and voter intent aside, this behavior is misleading and
inconsistent with previous kernels. Tools like top or a CPU dock applet show
a constantly loaded CPU. Hacking them to deduct the load from 'kapm-idled'
seems like the wrong answer.
stewart
On Mon, 11 Dec 2000, Rik van Riel wrote:
> On Mon, 11 Dec 2000 [email protected] wrote:
>
> [snip whine]
>
> > I've consistently re-produced this on my Dell Latitude CS laptop. I'm
> > wondering if this will reduce battery life since the CPU is constantly
> > being loaded instead of properly idled.
>
> What do you suppose the 'idled' in 'kapm-idled' stands for?
>
> Rik
> Technical merits and voter intent aside, this behavior is misleading and
> inconsistent with previous kernels. Tools like top or a CPU dock applet show
the goal of kernel revision is *not* to remain consistent with old stuff.
> a constantly loaded CPU. Hacking them to deduct the load from 'kapm-idled'
> seems like the wrong answer.
so don't run APM already.
On Mon, 11 Dec 2000 [email protected] wrote:
>
> very helpful.
>
> Technical merits and voter intent aside, this behavior is misleading and
> inconsistent with previous kernels. Tools like top or a CPU dock applet show
> a constantly loaded CPU. Hacking them to deduct the load from 'kapm-idled'
> seems like the wrong answer.
>
> stewart
>
Err.. Did you see the comment about shared memory info being permanently
removed because (something about too CPU intensive to justify...)?
It looks like we need to find another way to get kernel info rather
than from /proc. We need to calculate stuff only when it's needed.
Calculating stuff all the time, to make it available should somebody
care to read it in the /proc file-system is wasteful.
Maybe we need to have some kind of 'kernel ioctl' where a user-mode caller
'pays' for the CPU cycles necessary to obtain the info that the caller
requests. A better idea might be to have the 'read' of a particular
/proc file-system item, result in the calculation of the new values.
That way, the read and calculation of new values gets charged to
the reader.
In any event, the continuous calculation of 'kernel stuff' that may
be read once a week at most, is definitely a waste of CPU cycles.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
On Mon, Dec 11, 2000 at 01:56:22PM -0500, [email protected] wrote:
> Technical merits and voter intent aside, this behavior is misleading and
> inconsistent with previous kernels. Tools like top or a CPU dock applet show
> a constantly loaded CPU. Hacking them to deduct the load from 'kapm-idled'
> seems like the wrong answer.
Even worse: Formerly you could take conclusions from the sys part of your
load. This is not possible any more.
I dislike this as well and consider it a cosmetical bug.
(Which is much better than a real bug, don't get me wrong. I fixing the
cosmetical one introduces a real one: Don't do it!)
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
Hi!
> Technical merits and voter intent aside, this behavior is misleading and
> inconsistent with previous kernels. Tools like top or a CPU dock applet show
> a constantly loaded CPU. Hacking them to deduct the load from 'kapm-idled'
> seems like the wrong answer.
I guess we should just put even normal idle thread to be visible in
ps. It is cleaner design, anyway.
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
Pavel Machek wrote:
> I guess we should just put even normal idle thread to be visible in
> ps. It is cleaner design, anyway.
How about adding a flag to FLAGS, or a new letter in STATE in
/proc/pid/stat, to mean "this is an idle task"?
ps & top could easily by taught to recognise the flag.
-- Jamie
> How about adding a flag to FLAGS, or a new letter in STATE in
> /proc/pid/stat, to mean "this is an idle task"?
>
> ps & top could easily by taught to recognise the flag.
What's the problem with using PID 0 as the idle task ? That's 'standard'
with OS'ses that display the idle task.
It's also the 'right' thing to do, and should directly work with top / ps
Igmar
Hi!
> > How about adding a flag to FLAGS, or a new letter in STATE in
> > /proc/pid/stat, to mean "this is an idle task"?
> >
> > ps & top could easily by taught to recognise the flag.
>
> What's the problem with using PID 0 as the idle task ? That's 'standard'
> with OS'ses that display the idle task.
Linux has already another thread with pid 0, called "swapper" which is
in fact idle. kidle-apmd is different beast.
> It's also the 'right' thing to do, and should directly work with top / ps
Yes, we should make pid 0 visible to userlnad, agreed.
Pavel
--
The best software in life is free (not shareware)! Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
> > What's the problem with using PID 0 as the idle task ? That's 'standard'
> > with OS'ses that display the idle task.
>
> Linux has already another thread with pid 0, called "swapper" which is
> in fact idle. kidle-apmd is different beast.
Agree that it is different. But it confuses people to have two
idle-tasks. I suggest that we throw it one big pile, unless having a
separate apm idle task has a purpose.
> Pavel
Igmar
Hi!
> > > What's the problem with using PID 0 as the idle task ? That's 'standard'
> > > with OS'ses that display the idle task.
> >
> > Linux has already another thread with pid 0, called "swapper" which is
> > in fact idle. kidle-apmd is different beast.
>
> Agree that it is different. But it confuses people to have two
> idle-tasks. I suggest that we throw it one big pile, unless having a
> separate apm idle task has a purpose.
You can't do that. Doing it this way is _way_ better for system
stability, because kidle-apmd sometimes dies due to APM
bug. kidle-apmd dying is recoverable error; swapper dieing is as fatal
as it can be.
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
>> Agree that it is different. But it confuses people to have two
>> idle-tasks. I suggest that we throw it one big pile, unless having a
>> separate apm idle task has a purpose.
>
> You can't do that.
Sure you can, and it makes perfect sense.
> Doing it this way is _way_ better for system
> stability, because kidle-apmd sometimes dies due to APM
> bug. kidle-apmd dying is recoverable error; swapper dieing is as fatal
> as it can be.
Good. Maybe the bugs will get fixed then. If the bugs are in
the BIOS or motherboard hardware, we can have a blacklist.
Hi!
> >> Agree that it is different. But it confuses people to have two
> >> idle-tasks. I suggest that we throw it one big pile, unless having a
> >> separate apm idle task has a purpose.
> >
> > You can't do that.
>
> Sure you can, and it makes perfect sense.
No. You lost the way to distinguish between real "idle" spend, and
kapm-idle spend -- they are different, in kapm-idle cpu is slowed down.
> > Doing it this way is _way_ better for system
> > stability, because kidle-apmd sometimes dies due to APM
> > bug. kidle-apmd dying is recoverable error; swapper dieing is as fatal
> > as it can be.
>
> Good. Maybe the bugs will get fixed then. If the bugs are in
> the BIOS or motherboard hardware, we can have a blacklist.
Ha ha. It was that way. Linus saw it was bad so he fixed it. Bugs are
discovered/fixed anyway, because you get ugly oops. But ugly oops is
better than even uglier oops that does not go to syslog and that kills
you machine hard, you see?
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
> > Agree that it is different. But it confuses people to have two
> > idle-tasks. I suggest that we throw it one big pile, unless having a
> > separate apm idle task has a purpose.
>
> You can't do that. Doing it this way is _way_ better for system
> stability, because kidle-apmd sometimes dies due to APM
> bug. kidle-apmd dying is recoverable error; swapper dieing is as fatal
> as it can be.
Hmm.. Means two idle task then :)
Igmar
> > Doing it this way is _way_ better for system
> > stability, because kidle-apmd sometimes dies due to APM
> > bug. kidle-apmd dying is recoverable error; swapper dieing is as fatal
> > as it can be.
>
> Good. Maybe the bugs will get fixed then. If the bugs are in
> the BIOS or motherboard hardware, we can have a blacklist.
If the're a lot of buggy APM BIOS'es out there it may indeed not be a wise
idea to throw everything on one pile.
Igmar