Re: [RFC PATCH v3 1/3] sched: schedule balance map foundation

2013-02-21 Thread Michael Wang
On 02/22/2013 12:46 PM, Alex Shi wrote: > On 02/22/2013 12:19 PM, Michael Wang wrote: >> Why not seek other way to change O(n^2) to O(n)? Access 2G memory is unbelievable performance cost. >> Not access 2G memory, but (2G / 16K) memory, the sbm size is O(N). >> >> And please notice t

Re: [RFC PATCH v3 1/3] sched: schedule balance map foundation

2013-02-21 Thread Alex Shi
On 02/22/2013 12:19 PM, Michael Wang wrote: > >> > Why not seek other way to change O(n^2) to O(n)? >> > >> > Access 2G memory is unbelievable performance cost. > Not access 2G memory, but (2G / 16K) memory, the sbm size is O(N). > > And please notice that on 16k cpus system, topology will be de

Re: [RFC PATCH v3 1/3] sched: schedule balance map foundation

2013-02-21 Thread Michael Wang
On 02/22/2013 11:33 AM, Alex Shi wrote: > On 02/22/2013 10:53 AM, Michael Wang wrote: >> And the final cost is 3000 int and 103 pointer, and some padding, >> but won't bigger than 10M, not a big deal for a system with 1000 cpu >> too. Maybe, but quadric stuff should b

Re: [RFC PATCH v3 1/3] sched: schedule balance map foundation

2013-02-21 Thread Alex Shi
On 02/22/2013 10:53 AM, Michael Wang wrote: >> > >>> >> And the final cost is 3000 int and 103 pointer, and some padding, >>> >> but won't bigger than 10M, not a big deal for a system with 1000 cpu >>> >> too. >> > >> > Maybe, but quadric stuff should be frowned upon at all times, these >> >

Re: [RFC PATCH v3 1/3] sched: schedule balance map foundation

2013-02-21 Thread Michael Wang
On 02/21/2013 07:37 PM, Peter Zijlstra wrote: > On Thu, 2013-02-21 at 12:58 +0800, Michael Wang wrote: >> >> You are right, it cost space in order to accelerate the system, I've >> calculated the cost once before (I'm really not good at this, please >> let >> me know if I make any silly calculation

Re: [RFC PATCH v3 1/3] sched: schedule balance map foundation

2013-02-21 Thread Peter Zijlstra
On Thu, 2013-02-21 at 12:58 +0800, Michael Wang wrote: > > You are right, it cost space in order to accelerate the system, I've > calculated the cost once before (I'm really not good at this, please > let > me know if I make any silly calculation...), The exact size isn't that important, but its

Re: [RFC PATCH v3 1/3] sched: schedule balance map foundation

2013-02-20 Thread Michael Wang
On 02/20/2013 09:25 PM, Peter Zijlstra wrote: > On Tue, 2013-01-29 at 17:09 +0800, Michael Wang wrote: >> +struct sched_balance_map { >> + struct sched_domain **sd[SBM_MAX_TYPE]; >> + int top_level[SBM_MAX_TYPE]; >> + struct sched_domain *affine_map[NR_CPUS]; >> +}; > > Argh.. af

Re: [RFC PATCH v3 1/3] sched: schedule balance map foundation

2013-02-20 Thread Michael Wang
On 02/20/2013 09:21 PM, Peter Zijlstra wrote: > On Tue, 2013-01-29 at 17:09 +0800, Michael Wang wrote: >> + for_each_possible_cpu(cpu) { >> + sbm = &per_cpu(sbm_array, cpu); >> + node = cpu_to_node(cpu); >> + size = sizeof(struct sched_domain *) * sbm

Re: [RFC PATCH v3 1/3] sched: schedule balance map foundation

2013-02-20 Thread Peter Zijlstra
On Tue, 2013-01-29 at 17:09 +0800, Michael Wang wrote: > +struct sched_balance_map { > + struct sched_domain **sd[SBM_MAX_TYPE]; > + int top_level[SBM_MAX_TYPE]; > + struct sched_domain *affine_map[NR_CPUS]; > +}; Argh.. affine_map is O(n^2) in nr_cpus, that's not cool. -- To un

Re: [RFC PATCH v3 1/3] sched: schedule balance map foundation

2013-02-20 Thread Peter Zijlstra
On Tue, 2013-01-29 at 17:09 +0800, Michael Wang wrote: > + for_each_possible_cpu(cpu) { > + sbm = &per_cpu(sbm_array, cpu); > + node = cpu_to_node(cpu); > + size = sizeof(struct sched_domain *) * sbm_max_level; > + > + for (type = 0; typ