lkml.org 
[lkml]   [2006]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2006-07-31 06:39    [W:0.029 / U:31.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site