Re: RFC for a new Scheduling policy/class in the Linux-kernel

[Raistlin <raistlin@linux.it>]

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

On Mon, 2009-07-13 at 12:14 +0200, Peter Zijlstra wrote:
> > Nice... Only one question, doesn't this impact with task affinity
> > related issues?
> 
> No :-), well maybe.
> 
:-D

> Since the task is blocked and will this not actually run, we can place
> it on any CPU, only once it becomes runnable again should we take care
> to place it on a CPU that's part of its affinity mask.
> 
Well, it's difficult to find an argument against this! :-)

Anyway, maybe if, on some architecture, for some kind of application,
the affinity may have been set to preserve some kind actual cache or
memory locality for the task access pattern, maybe this could be an
issue, couldn't it? :-)
I mean, in some case where being sure of having a task running on a
particular CPU is somehow of paramount importance...

Anyway, I know, I'm just wandering around, I'm not that "affinity
expert" and I'm far from having a real example of the scenario I tried
to describe! :-(

> Of course, underlying this is the question of what to do for
> 'partitioned' tasks sharing a resource. I think we've talked about this
> a few times.
>
Yes, there is a lot of chatting about partitioned task sets where
resource sharing crosses the partition in the literature...

> Since these 'partitioned' tasks do share a resource, they're not really
> all that partitioned, 
... and I definitely agree with you on that: where's partitioning?
Anyway, I also think that, if that is true, e.g., for user-space
locks/resources, there are resources that two tasks _have_ to share,
even if being partitioned, e.g., when they come to compete, in kernel
space, e.g., for a lock on the virtual terminal... And that's the only
situation where such a problem make sense.

These just to point out one more reason why we are trying something
different (as explained in the other message), and light year far from
saying that the approach you proposed is not the good one!

On the contrary, I think all this make the problem even more
interesting! :-)

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

http://blog.linux.it/raistlin / raistlin@ekiga.net /
dario.faggioli@jabber.org

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]