Hello, Tahsin. On Mon, Feb 27, 2017 at 12:37:59PM -0800, Tahsin Erdogan wrote: > > Ah, absolutely, that's a stupid failure but we should be able to fix > > that by making the blkg functions take gfp mask and allocate > > accordingly, right? It'll probably take preallocation tricks because > > of locking but should be doable. > > My initial goal was to allow calls to vmalloc(), but I now see the > challenges in that > approach. I'd love to see that working too but this is a different issue. Even GFP_ATOMIC can fail under pressure and it's kinda wrong to depend on that for userspace interactions. > Doing preallocations would probably work but not sure if that can be > done without > complicating code too much. Could you describe what you have in mind? So, blkg_create() already takes @new_blkg argument which is the preallocated blkg and used during q init. Wouldn't it work to make blkg_lookup_create() take @new_blkg too and pass it down to blkg_create() (and also free it if it doesn't get used)? Then, blkg_conf_prep() can always (or after a failure with -ENOMEM) allocate a new blkg before calling into blkg_lookup_create(). I don't think it'll complicate the code path that much. Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
