CPU usage (Read by `top`)

[Richard B. Johnson]

On Thu, 20 Jan 2000, Pavel Machek wrote:

> Hi!
> 
> > > > Now sched_yield(), itself, works well. The problem is that the task
> > > > that gave up the CPU is still being 'Charged' for it!
> > > 
> > > Well, I used to had worse case: software that sleeps "just before" it
> > > would be charged is charged 0% even if it eats 80% or so.
> > > 
> > > Clearly, cpu metering is broken. There's no easy way to fix it.
> > > 								Pavel
> > > -- 
> > 
> > Just wanted to get it into the queue of things that should be fixed
> > before the next big leap into some future improvement project that
> > sometimes leaves old bugs unfixed.
> 
> Well - it is not quite clear if this bug should be fixed.
> 
> Current method is very_low_overhead and wrong.
> 
> Is it worth to add overhead?
> 								Pavel

Well I don't know. Certainly when some task wants to give up the
CPU because it's waiting for an event, as long as the overhead gets
charged to that task only, it's not really overhead at all because
it doesn't affect other tasks.

I think that it probably is not a real big fix. If sched_yield() was
handled like usleep() on entry and return. The overhead affects only
the task that called sched_yield().

Right now, if I make a loop as "for(;;) sched_yield();" and then
another task executes `make -j 10 bzImage`, the entire observable
CPU time for the `make` is charged to the poor sucker who wanted
to be nice while waiting for an event.

Aside from making problems for future users who have to explain
to their <future> sysadmins that their wonderful programs are not
behaving badly, there is also the problem of testing the "goodness"
of a program on a single-user machine.

On the other hand, there are not too many user-mode programs that
would ever want to use sched_yield() because they would usually
poll using select() or pause() for a signal.

But, some junk hardware has to be handled that doesn't use interrupts
and only signals its state with some bits in a port. Such hardware
wouldn't even run on an Alpha or a Sun. But with Linux on Intel, we
can currently do "anything". This poll stuff can run from user-space.
I don't even need a driver. Just iopl(3) and away we go. It would be
nice if it looked as good as it works!

Cheers,
Dick Johnson

Penguin : Linux version 2.3.39 on an i686 machine (800.63 BogoMips).


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/