Re: [RFC tg_shares_up improvements - v1 00/12] [RFC tg_shares_up - v100/12] Reducing cost of tg->shares distribution

[Paul Turner]

On Sat, Oct 16, 2010 at 12:46 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> On Fri, 2010-10-15 at 21:43 -0700, pjt@xxxxxxxxxx wrote:
>> Hi all,
>>
>> Peter previously posted a patchset that attempted to improve the problem of
>> task_group share distribution.  This is something that has been a long-time
>> pain point for group scheduling.  The existing algorithm considers
>> distributions on a per-cpu-per-domain basis and carries a fairly high update
>> overhead, especially on larger machines.
>>
>> I was previously looking at improving this using Fenwick trees to allow a
>> single sum without the exorbitant cost but then Peter's idea above was better :).
>>
>> The kernel is that by monitoring the average contribution to load on a
>> per-cpu-per-taskgroup basis we can distribute the weight for which we are
>> expected to consume.
>>
>> This set extends the original posting with a focus on increased fairness and
>> reduced convergence (to true average) time.  In particular the case of large
>> over-commit in the case of a distributed wake-up is a concern which is now
>> fairly well addressed.
>>
>> Obviously everything's experimental but it should be stable/fair.
>
> I like what you've done with it, my only worry is 10/12 where you allow
> for extra updates to the global state -- I think they should be fairly
> limited in number, and I can see the need for the update if we get too
> far out of whack, but it is something to look at while testing this
> stuff.
>

So my original answer here was to only update when there was load and
it was > n% delta which stops 1 thread waking up and sleeping from
thrashing it, but the 2 thread case is just as obviously broken for
any n.  It needs a rate limit but I'm sort of loathe to introduce
_another_ set of timestamps.  I don't suppose there's much harm in
doing so though and I don't think it's going to be clean to overload
one of the existing ones so perhaps another counter is the answer.

I'll make sure this is addressed in v2.

>> TODO:
>> - Validate any RT interaction
>
> I don't think there's anything to worry about there, the only
> interaction which there is between this and the rt scheduling classes is
> the initial sharing of the load-avg window, but you 'cure' that in 7/12.
>
> (I think that sysctl wants a _us postfix someplace and we thus want some
> NSEC_PER_USEC multiplication in there).
>

Yes -- updated, thanks.

>> - Continue collecting/analyzing performance and fairness data
>
> Yes please ;-), I'll try and run this on some machines as well.
>
>> - Should the shares period just be the sched_latency?
>
> Interesting idea.. lets keep it a separate sysctl for now for easy
> tuning, if things settle down and we're still good in that range we can
> consider merging them.
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/