lkml.org 
[lkml]   [2005]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]

* Paul Jackson <pj@engr.sgi.com> 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-06 13:31    [W:0.085 / U:0.796 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site