On Mon, 23 Apr 2007, Ingo Molnar wrote:
>
> The "give scheduler money" transaction can be both an "implicit
> transaction" (for example when writing to UNIX domain sockets or
> blocking on a pipe, etc.), or it could be an "explicit transaction":
> sched_yield_to(). This latter i've already implemented for CFS, but it's
> much less useful than the really significant implicit ones, the ones
> which will help X.
Yes. It would be wonderful to get it working automatically, so please say
something about the implementation..
The "perfect" situation would be that when somebody goes to sleep, any
extra points it had could be given to whoever it woke up last. Note that
for something like X, it means that the points are 100% ephemeral: it gets
points when a client sends it a request, but it would *lose* the points
again when it sends the reply!
So it would only accumulate "scheduling points" while multiuple clients
are actively waiting for it, which actually sounds like exactly the right
thing. However, I don't really see how to do it well, especially since the
kernel cannot actually match up the client that gave some scheduling
points to the reply that X sends back.
There are subtle semantics with these kinds of things: especially if the
scheduling points are only awarded when a process goes to sleep, if X is
busy and continues to use the CPU (for another client), it wouldn't give
any scheduling points back to clients and they really do accumulate with
the server. Which again sounds like it would be exactly the right thing
(both in the sense that the server that runs more gets more points, but
also in the sense that we *only* give points at actual scheduling events).
But how do you actually *give/track* points? A simple "last woken up by
this process" thing that triggers when it goes to sleep? It might work,
but on the other hand, especially with more complex things (and networking
tends to be pretty complex) the actual wakeup may be done by a software
irq. Do we just say "it ran within the context of X, so we assume X was
the one that caused it?" It probably would work, but we've generally tried
very hard to avoid accessing "current" from interrupt context, including
bh's..
Linus
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
