Messages in this thread | | | Date | Thu, 20 Jan 2000 15:53:12 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: CPU usage (Read by `top`) |
| |
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@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |