* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> > central tunable:
> >
> > /proc/sys/kernel/sched_granularity_ns
> >
> > which can be used to tune the scheduler from 'desktop' (low
> > latencies) to 'server' (good batching) workloads. It defaults to a
> > setting suitable for desktop workloads. SCHED_BATCH is handled by the
> > CFS scheduler module too.
>
> I find this useful, but to be fair with Mike and Con, they both have
> proposed similar tuning knobs in the past and you said you did not
> want to add that complexity for admins. [...]
yeah. [ Note that what i opposed in the past was mostly the 'export all
the zillion of sched.c knobs to /sys and let people mess with them' kind
of patches which did exist and still exist. A _single_ knob, which
represents basically the totality of parameters within sched_fair.c is
less of a problem. I dont think i ever objected to this knob within
staircase/SD. (If i did then i was dead wrong.) ]
> [...] People can sometimes be demotivated by seeing their proposals
> finally used by people who first rejected them. And since both Mike
> and Con both have done a wonderful job in that area, we need their
> experience and continued active participation more than ever.
very much so! Both Con and Mike has contributed regularly to upstream
sched.c:
$ git-log kernel/sched.c | grep 'by: Con Kolivas' 1 | wc -l
19
$ git-log kernel/sched.c | grep 'by: Mike' | wc -l
6
and i'd very much like both counts to increase steadily in the future
too :)
> > - reworked/sanitized SMP load-balancing: the runqueue-walking
> > assumptions are gone from the load-balancing code now, and
> > iterators of the scheduling modules are used. The balancing code
> > got quite a bit simpler as a result.
>
> Will this have any impact on NUMA/HT/multi-core/etc... ?
it will inevitably have some sort of effect - and if it's negative, i'll
try to fix it.
I got rid of the explicit cache-hot tracking code and replaced it with a
more natural pure 'pick the next-to-run task first, that is likely the
most cache-cold one' logic. That just derives naturally from the rbtree
approach.
> > the core scheduler got smaller by more than 700 lines:
>
> Well done !
thanks :)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
