lkml.org 
[lkml]   [2017]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] drm: use kvmalloc_array for drm_malloc*
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@suse.com>
> > > > > >
> > > > > > 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

\
 
 \ /
  Last update: 2017-05-17 10:11    [W:0.098 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site