From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from parasite.irisa.fr (parasite.irisa.fr [131.254.12.47]) by kvack.org (8.8.7/8.8.7) with ESMTP id CAA01216 for ; Tue, 21 Apr 1998 02:48:05 -0400 Subject: Re: bigphysarea in 2.2 References: <199804101746.KAA15720@halibut.imedia.com> <199804202157.WAA03987@dax.dcs.ed.ac.uk> Mime-Version: 1.0 (generated by tm-edit 7.95) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit From: David Mentre Date: 21 Apr 1998 08:44:01 +0200 In-Reply-To: "Stephen C. Tweedie"'s message of "Mon, 20 Apr 1998 22:57:51 +0100" Message-ID: Sender: owner-linux-mm@kvack.org To: "Stephen C. Tweedie" Cc: pmonta@imedia.com, steve@icarus.icarus.com, linux-kernel@vger.rutgers.edu, linux-mm@, @kvack.org List-ID: "Stephen C. Tweedie" writes: > me: > > With the new kernel memory manager, and if the defragmenting code which > > is under development works, wouldn't it be more useful to use standard > > kernel memory allocation. Static allocation like in bigphysarea is more > > a work-around that a real solution. > > Unfortunately, the current code simply doesn't grok areas larger than > 128KB, and even if it did, it is unlikely that it could be made to > work well in that case --- the existance of just one non-pagable > allocation (slab, kmalloc, page table etc.) in any 512K block would > render that entire region unreclaimable by the swapper. If you need > such large physically contiguous regions, then bigphysarea is still > a better option. Ok, I have understood. The last problem is that driver using the bigphysarea need a patched kernel. It's annoying (at least for a production kernel). But it seems from recent discussions that a lobbying group tries to incorporate it in the mainstream kernel. ;) I vote for it, as this patch is more and more necessary (and because it seems to be _the_ solution for big allocations). Regards, d. -- David.Mentre@irisa.fr -- Perso : http://www.irisa.fr/prive/dmentre/ == GNU et Linux : Ameliorer _notre_ monde ==