* Paul Jackson <[EMAIL PROTECTED]> wrote:
> Ingo, if I understood correctly, suggested pushing any necessary
> detail of the CPU hierarchy into the scheduler domains, so that his
> latest work tuning migration costs could pick it up from there.
>
> It makes good sense for the migration cost estimation to be based on
> whatever CPU hierarchy is visible in the sched domains.
>
> But if we knew the CPU hierarchy in more detail, and if we had some
> other use for that detail (we don't that I know), then I take it from
> your comment that we should be reluctant to push those details into
> the sched domains. Put them someplace else if we need them.
There's no other place to push them - most of the hierarchy related
decisions are done based on the domain tree. So the decision to make is:
"is it worth complicating the domain tree, in exchange for more accurate
handling of the real hierarchy?".
In general, the pros are potentially more accuracy and thus higher
application performance, the cons are overhead (more tree walking) and
artifacts (the sched-domains logic is good but not perfect, and even if
there were no bugs in it, the decisions are approximations. One more
domain level might make things worse.)
but trying and benchmarking it is necessary to tell for sure.
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/
