From: Hubertus F. <fr...@us...> - 2001-07-16 18:27:17
|
Well, actually the sole purpose of <has_cpu> is to lock a task out of a scheduling decision. Remember during transient states, there are two tasks that have the <has_cpu> flag set for a particular cpu. So I think using <has_cpu> is kosher and preferred in this situation, IMHO. As you saw from David Levines reply, he thinks that a list is more appropriate for more generic decision support. But I don't like the fact that you lock down several tasks at that point. In my solution, you return the task back to general schedulability. Hubertus Franke Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability) email: fr...@us... Mike Kravetz <mkr...@se...> on 07/16/2001 12:14:46 PM To: Hubertus Franke/Watson/IBM@IBMUS cc: Mike Kravetz <mkr...@se...>, lse...@li..., lin...@vg... Subject: Re: CPU affinity & IPI latency On Fri, Jul 13, 2001 at 11:25:21PM -0400, Hubertus Franke wrote: > > Mike, could we utilize the existing mechanism such as has_cpu. > I like it. Especially the way you eliminated the situation where we would have multiple tasks waiting for schedule. Hope this is not a frequent situation!!! The only thing I don't like is the use of has_cpu to prevent the task from being scheduled. Right now, I can't think of any problems with it. However, in the past I have been bit by using fields for purposes other than what they were designed for. -- Mike Kravetz mkr...@se... IBM Linux Technology Center |