Re: [RFC][PATCH 00/26] sched/numa

[Andrea Arcangeli]

On Mon, Mar 19, 2012 at 04:06:43PM +0200, Avi Kivity wrote:
> I agree with Peter on this, but perhaps it's because my app will take
> all of 15 minutes to patch.  Up front knowledge is better than the
> kernel discovering it on its own.

I agree for qemu those soft bindings are fine.

But how you compute the statistical data is most difficult part, how
you collect them not so important after all.

The scheduler code Peter said is "that's not going to ever happen"
took several weeks of benchmarking and several rewrites to actual
materialize and be super happy about the core algorithm. If it's
simplified and just loops over the CPUs is because when you do
research and invent you can't waste time on actual implementation
details that just slow you down on the next rewrite of the algorithm
as you have to try again. So if my algorithms (abeit in a simplified
form compared to a real full implementation) works better, not having
the background scanning won't help Peter at all and you'll still be
better off with AutoNUMA.

When you focus only on the cost of collecting the information and no
actual discussion was spent yet on how to compute or react to it,
something's wrong... as that's the really interesting part of the code.

The fact the autonuma_balance() is simplified implementation is still
perfectly ok right now, as that's totally hidden kernel internal
thing, not even affecting kABI. Can be improved any time. Plus it's
not like it will backfire, it just won't be running as good as a full
more complex implementation that takes into account all the
runqueues. And implementating that won't be easy at all, there are
simpler things that are more urgent at this point.
--
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/