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 3:32 PM
> > > > But you keep on missing the point that this only happens in the initial
> > > > stage of tasks competing for CPU resources.
> > > >
> > > > If this is broken, then current smt nice is equally broken with the
> > > > same reasoning: once the low priority task gets scheduled, there is
> > > > nothing to kick it off the CPU until its entire time slice get used up.
> > > >  They compete equally with a high priority task running on the sibling
> > > > CPU.
> > >
> > > There has to be some way of metering it out and in the absence of cpu
> > > based hardware priority support (like ppc64 has) the only useful thing we
> > > have to work with is timeslice. Yes sometimes the high priority task is
> > > at the start and sometimes at the end of the timeslice but overall it
> > > balances the proportions out reasonably fairly.
> >
> > Good!  Then why special case the initial stage?  Just let task run and it
> > will even out statistically.  Everyone is happy, less code, less special
> > case, same end result.
> 
> Hang on I think I missed something there. What did you conclude I conceded 
> there? When I say "work with timeslice" I mean use percentage of timeslice 
> the way smt nice currently does.


You haven't answered my question either.  What is the benefit of special
casing the initial stage of cpu resource competition?  Is it quantitatively
measurable?  If so, how much and with what workload?

Also there are oddness in the way that the sleep decision is made: 75% of
resched decision is to sleep, while 25% of the time is to run, but there
are fussiness in there and all depends on when the resched and time slice
expires.  Considering a scenario when resched occurs on jiffies%100 = 10,
and low priority task time slice of 100 jiffies, the current code always
decide to run the low priority task!

 if (rt_task(smt_curr)) {
    /*
     * With real time tasks we run non-rt tasks only
     * per_cpu_gain% of the time.
     */
    if ((jiffies % DEF_TIMESLICE) >
       (sd->per_cpu_gain * DEF_TIMESLICE / 100))
             ret = 1;


The whole point is: precise fairness can not be (or difficult to) control
at milli-second range.  It all will work out statistically in a long run.
Which again brings back the question: what does the special casing in
precision control will bring to the overall scheme?  So far, I have not
seen any quantitative measure at all that indicates it is a win.

- Ken