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 <mho...@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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
