On Thu, 04 Sep 2008 17:34:03 +1000 Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > I could not think of anything simple so far and I'm open for suggestions. > > > > > > GFP_KERNEL should not fail, it will just block no ? > > > > No it won't block and will fail (returns NULL). > > hrm... it used to never fail.. that may have changed. But it will > definitely block and try very hard to push things out to make space, > which is the whole point :-) Right, but it still can fail - and you're right, we're in trouble already. Last time I dug into slab code I got lost into the maze :( > > > I will have to add that back as there is no more fallback. > > Well, the must be one in the case the tree isn't initialized yet, > so if > there's an allocation failure, you may "de-initialize" it or > something... There's nothing to 'de-initialize' here, or am I missing something? radix_tree_insert() will return ENOMEM and won't insert anything. > Or you can fallback if you don't find, as easy, probably > easier since it shouldn't happen in practice. That's what I had in mind. > > > > I don't know if it's worth trying to fire off a new > > > allocation attempt later, probably not. > > > > I've been pondering with this lately, but I think that adding a linear > > lookup fallback should be OK. > > Yup. > Thanks Ben, Sebastien. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
