Bruce F. Press wrote:
> Yes, yes, we've heard this before. It is not a satisfactory answer,
> clearly the "idle" loop in kapm-idled could use a nice sleep(15) or
> something!!
What would be a satisfactory answer?
Are you concerned because top shows the system being far busier than it
really is?
(Then maybe we need a modified top that does not count kapm-idled as
processor usage in the "CPU States" percentage.)
Do you disbelieve what you are being told (that, IIUC, the time used by
kapm-idled is really system idle time that will transparently and
instantaneously be applied to a real task if one exists and is ready to
run)? If so, do you have any evidence of this -- is your system running
slowly or more slowly than you would expect / are used to?
I'm serious about these questions, not trying to be a smart ass. The
story being told is believable to me. But, I keep hearing that Linux's
approach of using all available RAM (not paraphrased accurately) is the
best approach, yet in a Windows 95 system with 64 MB of memory I can
keep 30 IE 5 windows open and get snappy response switching between
windows, yet in a Linux (Mandrake 7.2) system with 128 MB of RAM (and
comparable processors, identical motherboards and video cards),
everything works much slower even with only one window open, and by the
time I get to 15 to 20 open (Konqueror 2.0 or 2.1) windows, the system
is like molasses.
I think part of the problem is theat kde/konqueror need to learn some of
the tricks that Windows uses. I can't describe those tricks accurately,
but I see the results. One example: in Windows, if I create a new
instance of IE, it appears almost instantly, and the disk doesn't make a
peep. In Linux, if I do the same thing in konqueror, the disk starts
chugging, and 15 to 45 seconds later the new instance of konqueror
appears (and on the wrong desktop if I've switched desktops in the
interim).
Don't get me wrong, I want Linux to succeed, but I think some new tricks
are needed. (Also, in Linux, if I make some wrong keystrokes, it seems
that they are all queued up and executed (slowly) one after the other.
In Windows, it seems that if I type (or click) the wrong command, but
then type (or click) the right command, the initial incorrect command is
interrupted and never completed (at least under some circumstances). I
know I am not describing this stuff accurately or completely, but it
sure makes a Windows system much more responsive than a Linux system.
And yes, "until it crashes" -- but I have learned to watch my resource
usage in Windows and reboot once or twice a week whether I need to or
not, and thus rarely if ever get a crash. Yes, I would prefer not to
have to reboot periodically, but I get more done quicker in Windows
between reboots that I do in Linux waiting for the molasses.
If you (anyone) can collaborate these stories, and help me get them to
the right developers, it would be to the benefit of all of us. I don't
know whether these things need to be addressed at the OS level or the
desktop level, or someplace else, but someone needs to consider them.
(And, if the desktop developers tell me they can do nothing, it all
depends on the OS developers, I will not believe them. I might believe
that the cleanest fix must be done at the OS level (if that's what they
tell me), but I believe that fixes can also be done at lower levels.
Perhaps performance can be improved by always keeping a buffer of free
RAM large enough to immediately clone a konqueror window. At the
desktop level, one or more such buffers can be created, even if you do
something dumb like precreating an unused instance of konqueror. Then,
when an instance of konqueror is requested, display this one immediately
(with no disk chugging). Then start the disk chugging to create another
free buffer for the next request.
I know these kind of things can be done. I am not enough (or any) of a
programmer to do them myself. I imagine all the developers are busy
doing important things. Are they aware of and planning to implement
techniques like these, or better?
If this email has any value, please feel free to copy or quote portions
of it to anyone, anywhere, anytime.
Thanks,
Randy Kramer
> Chmouel Boudjnah wrote:
> >
> > SI Reasoning <[EMAIL PROTECTED]> writes:
> >
> > > There are good stretches of the day where my CPU spins
> > > at around 50% or more and the process spinning is
> > > kapm-idled. This is not a problem in 7.2.
> >
> > --=-=-=
> > http://www.tux.org/lkml/#s14-1:
> >
> > 1.Why is kapmd using so much CPU time?
> > (REG) Don't worry, it's not stealing valuable CPU time from
> > other processes. It's just consuming idle cycles (normally
> > charged to the idle task, which is displayed differently in
> > top). Normally, when your system is idle, the system idle
> > task is run, and this is shown as idle time (i.e. the "unused"
> > CPU time is not charged to a specific process). With APM
> > (Advanced Power Management), a special idle task (kapmd) is
> > required so that greater power saving techniques can be
> > enabled. So now, the "unused" CPU time is charged to the kapmd
> > task instead.
> >
> > --=-=-=
> >
> > --=-=-=
> > http://olstrans.sourceforge.net/release/OLS2000-apm/OLS2000-apm.html:
> >
> > In 2.2 and before, we basically had a hook into the idle loop, so that
> > if we had APM enabled, we would just tell the BIOS that we're
> > idle. In 2.3, Linus thought it would be a good idea if we had a
> > separate power management idle loop, so (he) we invented the
> > kernel APM daemon and I started getting bug reports about this
> > process that was using all our time, called kapmd. And if you sat
> > there just running top on a 2.3 kernel, the top process, if you're
> > not doing anything else, will be kapmd and it will be using like
> > 85% or 90% or 95% of your CPU time. These people were worried
> > because it was idle: why is it using all of the time? Well
> > actually, it's just that the time is getting accounted to that
> > process. It's not doing anything, it's the idle loop. [26m, 12s]
> > --=-=-=
> >
> > --
> > MandrakeSoft Inc http://www.chmouel.org
> > --Chmouel
>
> ---------------------------------------------------------------
>
> Name: brucefp.vcf
> Part 1.2 Type: text/x-vcard
> Encoding: 7bit
> Description: Card for Bruce F. Press
