Re: [PATCH] drm: use kvmalloc_array for drm_malloc*

[Michal Hocko]

On Wed 17-05-17 08:59:44, Chris Wilson wrote:
> On Wed, May 17, 2017 at 09:44:53AM +0200, Michal Hocko wrote:
> > On Tue 16-05-17 12:09:08, Chris Wilson wrote:
> > > On Tue, May 16, 2017 at 12:53:52PM +0200, Michal Hocko wrote:
> > > > On Tue 16-05-17 10:31:19, Chris Wilson wrote:
> > > > > On Tue, May 16, 2017 at 11:06:06AM +0200, Michal Hocko wrote:
> > > > > > From: Michal Hocko <mhocko@xxxxxxxx>
> > > > > > 
> > > > > > drm_malloc* has grown their own kmalloc with vmalloc fallback
> > > > > > implementations. MM has grown kvmalloc* helpers in the meantime. Let's
> > > > > > use those because it a) reduces the code and b) MM has a better idea
> > > > > > how to implement fallbacks (e.g. do not vmalloc before kmalloc is tried
> > > > > > with __GFP_NORETRY).
> > > > > 
> > > > > Better? The same idea. The only difference I was reluctant to hand out
> > > > > large pages for long lived objects. If that's the wisdom of the core mm,
> > > > > so be it.
> > > > 
> > > > vmalloc tends to fragment physical memory more os it is preferable to
> > > > try the physically contiguous request first and only fall back to
> > > > vmalloc if the first attempt would be too costly or it fails.
> > > 
> > > Not relevant for the changelog in this patch, but it would be nice to
> > > have that written in kvmalloc() as to why the scatterring of 4k vmapped
> > > pages prevents defragmentation when compared to allocating large pages.
> > 
> > Well, it is not as much about defragmentation because both vmapped and
> > kmalloc allocations are very likely to be unmovable (at least
> > currently). Theoretically there shouldn't be a problem to make vmapped
> > pages movable as the ptes can be modified but this is not implemented...
> > The problem is that vmapped pages are more likely to break up more
> > larger order blocks. kmalloc will naturally break a single larger block.
> > 
> > > I have vague recollections of seeing the conversation, but a summary as
> > > to the reason why kvmalloc prefers large pages will be good for future
> > > reference.
> > 
> > Does the following sound better to you?
> > 
> > diff --git a/mm/util.c b/mm/util.c
> > index 464df3489903..87499f8119f2 100644
> > --- a/mm/util.c
> > +++ b/mm/util.c
> > @@ -357,7 +357,10 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)
> >  	WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
> >  
> >  	/*
> > -	 * Make sure that larger requests are not too disruptive - no OOM
> > +	 * We want to attempt a large physically contiguous block first because
> > +	 * it is less likely to fragment multiple larger blocks and therefore
> > +	 * contribute to a long term fragmentation less than vmalloc fallback.
> > +	 * However make sure that larger requests are not too disruptive - no OOM
> >  	 * killer and no allocation failure warnings as we have a fallback
> >  	 */
> 
> Hmm, shouldn't we also teach vmalloc to allocate large chunks where
> possible - even mixing huge and normal pages? As well as avoiding pinning
> the pages and allowing migration.

Yes that would be possible and my vague recollection is that somebody
was working on something like that. Do not have any references, though.

> That comment is helping me to understand why the decison is made to
> favour kmalloc over vmalloc, thanks.

OK, I've sent this clarification to Andrew.

-- 
Michal Hocko
SUSE Labs