Messages in this thread | | | From | Vincent Guittot <> | Date | Tue, 7 Jan 2014 09:22:40 +0100 | Subject | Re: [RFC] sched: CPU topology try |
| |
On 6 January 2014 17:21, Peter Zijlstra <peterz@infradead.org> wrote: > On Wed, Dec 18, 2013 at 02:13:51PM +0100, Vincent Guittot wrote: >> This patch applies on top of the two patches [1][2] that have been proposed by >> Peter for creating a new way to initialize sched_domain. It includes some minor >> compilation fixes and a trial of using this new method on ARM platform. >> [1] https://lkml.org/lkml/2013/11/5/239 >> [2] https://lkml.org/lkml/2013/11/5/449 >> >> Based on the results of this tests, my feeling about this new way to init the >> sched_domain is a bit mitigated. > > Yay :-) > >> We can add more levels that will describe other dependency/independency like >> the frequency scaling dependency and as a result the final sched_domain >> topology will have additional levels (if they have not been removed during >> the degenerate sequence) > > Yeah, this 'creative' use of degenerate domains is pretty neat ;-)
thanks :-)
> >> My concern is about the configuration of the table that is used to create the >> sched_domain. Some levels are "duplicated" with different flags configuration >> which make the table not easily readable and we must also take care of the >> order because parents have to gather all cpus of its childs. So we must >> choose which capabilities will be a subset of the other one. The order is >> almost straight forward when we describe 1 or 2 kind of capabilities >> (package ressource sharing and power sharing) but it can become complex if we >> want to add more. > > I think I see what you're saying, although I hope that won't actually > happen in real hardware -- that said, people do tend to do crazy with > these ARM chips :/
it should be ok for ARM chip because the cores in a cluster share the same clock but it doesn't mean that it will not be possible in a near future or on other arch.
> > We should also try and be conservative in the topology flags we want to > add, which should further reduce the amount of pain here.
yes, i see a interest for powerdomain sharing and clock sharing flags so it should minimize the complexity
> > For now I do think this is a viable approach.. Yes its a bit cumbersome > for these asymmetric systems but it does give us enough to start > playing.
ok
Vincent > > I yet have to read Morton's emails on the P and C states, will try to > have a look at those tomorrow with a hopefully fresher brain -- somehow > its the end of the day already..
| |