* 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/
- Follow-Ups:
- References:
- RE: Industry db benchmark result on recent 2.6 kernels
- From: "Chen, Kenneth W" <[email protected]>
- [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
- From: Ingo Molnar <[email protected]>
- Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
- From: Paul Jackson <[email protected]>
- Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
- From: Ingo Molnar <[email protected]>
- Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
- From: Paul Jackson <[email protected]>
- Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
- From: Paul Jackson <[email protected]>
- Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
- From: Ingo Molnar <[email protected]>
- Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
- From: Paul Jackson <[email protected]>
- Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
- From: Nick Piggin <[email protected]>
- Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
- From: Paul Jackson <[email protected]>
- RE: Industry db benchmark result on recent 2.6 kernels
- Prev by Date: Re: [PATCH 4/4] psmouse: dynamic protocol switching via sysfs
- Next by Date: Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
- Previous by thread: Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
- Next by thread: Re: [patch] sched: auto-tune migration costs [was: Re: Industry db benchmark result on recent 2.6 kernels]
- Index(es):