On Tue 13-12-16 13:55:46, Andreas Dilger wrote: > On Dec 13, 2016, at 3:14 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > Are there any more comments or objections to this patch? Is this a good > > start or kv[mz]alloc has to provide a way to cover GFP_NOFS users as > > well in the initial version. > > I'm in favour of this cleanup as a starting point. I definitely agree > that this same functionality is in use in a number of places and should > be consolidated. > > The vmalloc() from GFP_NOFS can be addressed separately in later patches. > That is an issue for several filesystems, and while XFS works around this, > it would be better to lift that out of the filesystem code into the VM. Well, my longer term plan is to change how GFP_NOFS is used from the fs code rather than tweak the VM layer. The current situation with the nofs is messy and confusing. In many contexts it is used without a good reason - just to be sure that nothing will break. I strongly believe that we should use a scope api [1] which marks whole regions of potentially reclaim dangerous code paths and all the allocations within that region will inherit the nofs protection automatically. That would solve the vmalloc(GFP_NOFS) problem as well. The route to get there is no short or easy. I am planning to repost the scope patchset hopefully soon with ext4 converted. [1] http://lkml.kernel.org/r/1461671772-1269-1-git-send-email-mhocko@xxxxxxxxxx > Really, there are several of things about vmalloc() that could improve > if we decided to move it out of the dog house and allow it to become a > first class citizen, but that needs a larger discussion, and you can > already do a lot of cleanup with just the introduction of kvmalloc(). > > Since this is changing the ext4 code, you can add my: > > Reviewed-by: Andreas Dilger <adilger@xxxxxxxxx> thanks! -- Michal Hocko SUSE Labs -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
