Hi,
on a fairly old box used as a desktop (PII 300 Mhz with 196M RAM), I
observe the following strange behavior which I believe comes from the
kernel.
There's a VoIP known 'P2P' closed source application running, an IP
tables based firewall and a remote ssh session initiated. When using
top, sorting by CPU usage, no program is using more than a couple of
percent of CPU. On the other side, the total CPU user time is at
around 40%, with a 1.5 load average. Memory looks OK. The machine is
responsive as usual.
So I wonder why the cpu user time is at 40% without any particular
program showing as using CPU in the top listing. 'Problem' was
reproducible with 2.4.x and now with 2.6.8.1.
So it this a real problem or is there something that I don't
understand in particular? Thanks for the insight.
Jerome
The load and the CPU useage are two separate things:
Load: Defined by a programmer on an estimate on which his program is running
100% fulltime, thus consuming little or more CPU/IO.
The interesting program you mention is the VoIP application. Is this program
multithreaded and is every thread using a little bit of CPU? Than it quickly
adds up to the mentioned 40%. The load is than also easily reached.
On Monday 03 January 2005 22:46, jerome lacoste wrote:
> Hi,
>
> on a fairly old box used as a desktop (PII 300 Mhz with 196M RAM), I
> observe the following strange behavior which I believe comes from the
> kernel.
>
> There's a VoIP known 'P2P' closed source application running, an IP
> tables based firewall and a remote ssh session initiated. When using
> top, sorting by CPU usage, no program is using more than a couple of
> percent of CPU. On the other side, the total CPU user time is at
> around 40%, with a 1.5 load average. Memory looks OK. The machine is
> responsive as usual.
>
> So I wonder why the cpu user time is at 40% without any particular
> program showing as using CPU in the top listing. 'Problem' was
> reproducible with 2.4.x and now with 2.6.8.1.
>
> So it this a real problem or is there something that I don't
> understand in particular? Thanks for the insight.
>
> Jerome
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Tue, 4 Jan 2005 08:51:23 +0100, Norbert van Nobelen
<[email protected]> wrote:
> The load and the CPU useage are two separate things:
> Load: Defined by a programmer on an estimate on which his program is running
> 100% fulltime, thus consuming little or more CPU/IO.
> The interesting program you mention is the VoIP application. Is this program
> multithreaded and is every thread using a little bit of CPU? Than it quickly
> adds up to the mentioned 40%.
There are some threads in that app, not that many, and none show in
the top listing (which displays at least 30 entries). So I don't think
this sum scenario is valid.
>The load is than also easily reached.
On Tue, Jan 04, 2005 at 11:43:39AM +0100, jerome lacoste wrote:
> On Tue, 4 Jan 2005 08:51:23 +0100, Norbert van Nobelen
> <[email protected]> wrote:
> > The load and the CPU useage are two separate things:
> > Load: Defined by a programmer on an estimate on which his program is running
> > 100% fulltime, thus consuming little or more CPU/IO.
> > The interesting program you mention is the VoIP application. Is this program
> > multithreaded and is every thread using a little bit of CPU? Than it quickly
> > adds up to the mentioned 40%.
>
> There are some threads in that app, not that many, and none show in
> the top listing (which displays at least 30 entries). So I don't think
> this sum scenario is valid.
The correct display of threaded processes in top should be fixed by
the combination of procps-3.2.4 and the linux-2.6.10 kernel.
This according to the text in the announcement of procps-3.2.4.
I didn't test it yet, though.
Regards,
Toon.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan