Messages in this thread | | | From | Neil Brown <> | Date | Mon, 31 Jul 2006 14:36:09 +1000 | Subject | Re: [PATCH 010 of 11] knfsd: make rpc threads pools numa aware |
| |
On Sunday July 30, akpm@osdl.org wrote: > On Mon, 31 Jul 2006 10:42:34 +1000 > NeilBrown <neilb@suse.de> wrote: > > > +static int > > +svc_pool_map_init_percpu(struct svc_pool_map *m) > > +{ > > + unsigned int maxpools = num_possible_cpus(); > > + unsigned int pidx = 0; > > + unsigned int cpu; > > + int err; > > + > > + err = svc_pool_map_alloc_arrays(m, maxpools); > > + if (err) > > + return err; > > + > > + for_each_online_cpu(cpu) { > > + BUG_ON(pidx > maxpools); > > + m->to_pool[cpu] = pidx; > > + m->pool_to[pidx] = cpu; > > + pidx++; > > + } > > That isn't right - it assumes that cpu_possible_map is not sparse. If it > is sparse, we allocate undersized pools and then overindex them.
I don't think so.
At this point we are largely counting the number of online cpus (in pidx (pool index) - this is returned). The two-way mapping to_pool and pool_to provides a mapping between the possible-sparse cpu list and a dense list of pool indexes.
If further cpus come on line they will be automatically included in pool-0. (as to_pool[n] will still be zero).
Does that make it at all clearer?
Thanks, NeilBrown - 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/
| |