Messages in this thread | | | From | Con Kolivas <> | Subject | Re: [PATCH RFC] smt nice introduces significant lock contention | Date | Fri, 2 Jun 2006 19:34:26 +1000 |
| |
On Friday 02 June 2006 19:31, Chen, Kenneth W wrote: > Con Kolivas wrote on Friday, June 02, 2006 2:25 AM > > > On Friday 02 June 2006 19:17, Chen, Kenneth W wrote: > > > What about the part in dependent_sleeper() being so bully and actively > > > resched other low priority sibling tasks? I think it would be better > > > to just let the tasks running on sibling CPU to finish its current time > > > slice and then let the backoff logic to kick in. > > > > That would defeat the purpose of smt nice if the higher priority task > > starts after the lower priority task is running on its sibling cpu. > > But only for the duration of lower priority tasks' time slice. When lower > priority tasks time slice is used up, a resched is force from > scheduler_tick(), isn't it? And at that time, it is delayed to run because > of smt_nice. You are saying user can't tolerate that short period of time > that CPU resource is shared? It's hard to believe.
nice -20 vs nice 0 is 800ms vs 100ms. That's a long time to me.
-- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |