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@xxxxxxxxx / dario.faggioli@xxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
