From: "Christoph Lameter" <clameter sgi.com>
> Would it not be much simpler to use the SLIT table to
estimate the
> migration costs?
If the architecture has a SLIT, perhaps yes.
The current algorithm is very empirical: for a given pair
of CPUs, dirty the
L2 cache, migrate the task to the 2nd CPU, then measure how
long it takes to
redirty the data. The SLIT can give you some metric of
"distance" between two
CPUs or two nodes, but the scheduler is looking for
something it deems
directly related to the effects of migrating a cache-hot
task.
Again, my problem with the migration_cost is that it is
expensive to
calculate, and that the calculation takes pains to be
accurate to within
10-20%, and yet it makes assumptions (e.g., that the
migration cost between
cpu0 and cpu1 is the same as between cpu0 and cpu31) that
make its usefulness
questionable.
John Hawkes
-
To unsubscribe from this list: send the line
"unsubscribe linux-ia64" in
the body of a message to majordomo vger.kernel.org
More majordomo info at http://vge
r.kernel.org/majordomo-info.html
|