RE: [PATCH RFC] smt nice introduces significant lock contention

["Chen, Kenneth W" <kenneth.w.chen@intel.com>]

Con Kolivas wrote on Friday, June 02, 2006 2:34 AM
> 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.


Yeah, but that is the worst case though.  Average would probably be a lot
lower than worst case.  Also, on smt it's not like the current logical cpu
is getting blocked because of another task is running on its sibling CPU.
The hardware still guarantees equal share of hardware resources for both
logical CPUs.

- Ken

-
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/