lkml.org 
[lkml]   [2015]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [dm-devel] [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node
From
Date
Dne 7.7.2015 v 23:41 Andrew Morton napsal(a):
> On Tue, 7 Jul 2015 11:10:09 -0400 (EDT) Mikulas Patocka <mpatocka@redhat.com> wrote:
>
>> Introduce the functions kvmalloc and kvmalloc_node. These functions
>> provide reliable allocation of object of arbitrary size. They attempt to
>> do allocation with kmalloc and if it fails, use vmalloc. Memory allocated
>> with these functions should be freed with kvfree.
>
> Sigh. We've resisted doing this because vmalloc() is somewhat of a bad
> thing, and we don't want to make it easy for people to do bad things.
>
> And vmalloc is bad because a) it's slow and b) it does GFP_KERNEL
> allocations for page tables and c) it is susceptible to arena
> fragmentation.
>
> We'd prefer that people fix their junk so it doesn't depend upon large
> contiguous allocations. This isn't userspace - kernel space is hostile
> and kernel code should be robust.
>
> So I dunno. Should we continue to make it a bit more awkward to use
> vmalloc()? Probably that tactic isn't being very successful - people
> will just go ahead and open-code it. And given the surprising amount
> of stuff you've placed in kvmalloc_node(), they'll implement it
> incorrectly...

Hi

From my naive view: 4K-128K were nice restriction in the age of 16MB Pentium
machines - but the time has changed and now users need to work with TB of memory.

So if the kernel driver is going to maintain such a huge chunk - it could
hardly fit its resources into KB blocks.

So there are options - you could make complex code inside the driver to
address every little kmalloc-ed chunk (and have a lot of potential for bugs)
or you could always use vmalloc() and leave it on 'slow/GFP_KERNEL'.

So IMHO it's quite right to have the 'middle' road here - if there is enough
memory to proceed with kmalloc - fine and if not - then driver will be
somewhat slower but the coder will not have to spend months of coding
reinvention of the wheel...

Personally I even find 128K pretty small if this limit comes from MB era and
we are in the age of commonly available 32G laptops...

IMHO also it's kind of weird when kernel is not able to satisfy 128K
allocation if there are gigabytes of free RAM in my system - there should be
some defrag process running behind if there is such constrained kmalloc
interface...

Zdenek



\
 
 \ /
  Last update: 2015-07-08 10:01    [W:0.085 / U:1.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site