Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933644AbbGHHet (ORCPT ); Wed, 8 Jul 2015 03:34:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39554 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933511AbbGHHea (ORCPT ); Wed, 8 Jul 2015 03:34:30 -0400 Subject: Re: [dm-devel] [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node To: device-mapper development , Mikulas Patocka References: <20150707144117.5b38ac38efda238af8a1f536@linux-foundation.org> Cc: Mike Snitzer , Edward Thornber , linux-kernel@vger.kernel.org, linux-mm@kvack.org, "Alasdair G. Kergon" , David Rientjes , Linus Torvalds , Vivek Goyal From: Zdenek Kabelac Organization: Red Hat Message-ID: <559CD283.4020605@redhat.com> Date: Wed, 8 Jul 2015 09:34:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150707144117.5b38ac38efda238af8a1f536@linux-foundation.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2575 Lines: 57 Dne 7.7.2015 v 23:41 Andrew Morton napsal(a): > On Tue, 7 Jul 2015 11:10:09 -0400 (EDT) Mikulas Patocka 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/