On Thu, 13 Jul 2006 14:03:21 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:

>  > I suspect it'll get really ugly.  It's a container library which needs to
>  > allocate memory when items are added, like the radix-tree.  Either it needs
>  > to assume GFP_ATOMIC, which is bad and can easily fail or it does weird
>  > things like radix_tree_preload().
> 
> Actually I don't think it has to be too bad.  We could tweak the
> interface a little bit so that consumers do something like:
> 
>       struct idr_layer *layer = NULL; /* opaque */
> 
> retry:
>         spin_lock(&my_idr_lock);
>       ret = idr_get_new(&my_idr, ptr, &id, layer);
>         spin_unlock(&my_idr_lock);
> 
>         if (ret == -EAGAIN) {
>               layer = idr_alloc_layer(&my_idr, GFP_KERNEL);
>               if (!IS_ERR(layer))
>                       goto retry;
>       }
> 
> in other words make the consumer responsible for passing in new memory
> that can be used for a new entry (or freed if other entries have
> become free in the meantime).
> 

Good point, a try-again loop would work.  Do we really need the caller to
maintain a cache?  I suspect something like

drat:
        if (idr_pre_get(GFP_KERNEL) == ENOMEM)
                give_up();
        spin_lock();
        ret = idr_get_new();
        spin_unlock();
        if (ret == ENOMEM)
                goto drat;

would do it.

_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to