lkml.org 
[lkml]   [2022]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior
On Wed, Jan 19, 2022 at 09:44:20PM +0800, Kefeng Wang wrote:
>
> On 2022/1/19 21:22, Matthew Wilcox wrote:
> > On Wed, Jan 19, 2022 at 08:57:58PM +0800, Kefeng Wang wrote:
> > > Only parts of our products wants this feature,  we add some interfaces which
> > > only
> > >
> > > alloc hugevmalloc for them, eg,
> > > vmap_hugepage/vmalloc_hugepage/remap_vmalloc_hugepage_range..
> > >
> > > for our products, but it's not the choice of most products, also add
> > > nohugevmalloc
> > >
> > > for most products is expensive, so this is the reason for adding the patch.
> > >
> > > more config/cmdline are more flexible for test/products,
> > But why do only some products want it? What goes wrong if all products
> > enable it? Features should be auto-tuning, not relying on admins to
> > understand them.
>
> Because this feature will use more memory for vmalloc/vmap, that's why we
> add some explicit
> interfaces as said above in our kernel to control the user.

Have you validated that? What sort of performance penalty do you see?

\
 
 \ /
  Last update: 2022-01-19 14:48    [W:0.054 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site