On Tue, Feb 19 2008, KAMEZAWA Hiroyuki wrote:
> On Tue, 19 Feb 2008 09:36:34 +0100
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Feb 19 2008, KAMEZAWA Hiroyuki wrote:
> > > On Sun, 17 Feb 2008 20:29:13 +0100
> > > Jens Axboe <[EMAIL PROTECTED]> wrote:
> > >
> > > > It's odd stuff. Could you perhaps try and add some printks to
> > > > block/cfq-iosched.c:call_for_each_cic(), like dumping the 'nr' return
> > > > from radix_tree_gang_lookup() and the pointer value of cics[i] in the
> > > > for() loop after the lookup?
> > > >
> > > I met the same issue on ia64/NUMA box.
> > > seems cisc[]->key is NULL and index for radix_tree_gang_lookup() was
> > > always '1'.
> >
> > Why does it keep repeating then? If ->key is NULL, the next lookup index
> > should be 1UL.
> >
> when I inserted printk here
> ==
> for (i = 0; i < nr; i++)
> func(ioc, cics[i]);
> printk("%d %lx\n", nr, index);
> ==
> index was always "1" and nr was always 32.
>
> So, cics[31]->key was always NULL when index=1 is passed to
> radix_tree_gang_lookup().
Hang on, it returned 32? It should not return more than 16, since that
is what we have room for and asked for. Using ->dead_key when ->key is
NULL is correct btw, since that is the correct location in the tree once
the process has exited. But that should not happen until AFTER the
func() call, so I still think the list patch is safer.
> > But I think the radix 'scan over entire tree' is a bit fragile. This
> > patch adds a parallel hlist for ease of properly browsing the
> > members, does that work for you? It compiles, but I haven't booted
> > it here yet...
> >
> will try. please wait a bit.
It boots here, so at least it passes normal sanity tests. It should
solve your problem as well, hopefully.
--
Jens Axboe
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
