I don't think it is enough, and regarding logical binding, we're talking
past each other.
>Info about the data being transferred (address, amount) must exist somewhere,
>or data written to pipes would be lost. This is updated when
>someone writes into a pipe. The kernel could, during the write call,
>transfer some interactvity bonus (if any) and store it along with
>the other information about the pipe.
Well, yes, you can make a bucket to attach something to the data. What are
you going to attach to the data of irman's two completely independent pipe
rings that is going to prevent either one or the total of the irman process
from eating 100% cpu while I'm trying to login? See what I mean? When I
say logical binding, I mean an information bucket that the system can look
at and determine that process irman has had enough for now, and process
mikie_logs_is needs a shot of cpu, or process threaded application A vs
process monolithic application B.
It doesn't really matter that we're talking past each other though. IMHO,
the idea of spreading scheduling information around is at best horribly
ugly, and the idea of a process context is at best horribly
impractical. I'd stamp a 0xdeadbeef on both ;-)
>The pipe read call would simply grab any transferred bonus and
>add it to the reader's interactivity bonus. This should only be
>a few integer operations on either end of the pipe.
>The io boost calculated for disk/device operations surely amounts to some
>code too. It don't mess with every wakeup imaginable, this is specific to
However, I don't think that priority inflation is specific to pipes.
> > This is why I said I could _imagine_ a
> > process struct... as the container for this missing (it lives in userland)
> > information.
> > Another besides: it makes zero difference it you add overhead to wakeup
> > time or go to sleep time. If it's something you do a lot of, adding
> > overhead to it is going to hurt a lot.
>No doubt about that. Transferring an extra int per pipe read/write
>is overhead, I hope the data part of the transfer typically is much
>bigger than that.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/