Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 27 Jul 2002 12:53:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 27 Jul 2002 12:53:37 -0400 Received: from garrincha.netbank.com.br ([200.203.199.88]:23044 "HELO garrincha.netbank.com.br") by vger.kernel.org with SMTP id ; Sat, 27 Jul 2002 12:53:37 -0400 Date: Sat, 27 Jul 2002 13:56:40 -0300 (BRT) From: Rik van Riel X-X-Sender: riel@imladris.surriel.com To: David Woodhouse cc: Alan Cox , Russell Lewis , Subject: Re: Looking for links: Why Linux Doesn't Page Kernel Memory? In-Reply-To: <16918.1027787098@redhat.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1144 Lines: 34 On Sat, 27 Jul 2002, David Woodhouse wrote: > alan@lxorguk.ukuu.org.uk said: > > Memory is relatively cheap, and the complexity of such a paging > > kernel is huge (you have to pin down disk driver and I/O paths for > > example). Linux prefers to try to keep simple debuggable approaches to > > things. > > You could do it. Start with kmalloc_pageable ... Funny things are bound to happen when code gets preempted because of page faults... > It's debatable what kind of benefit it would give you over and above > just fixing specific cases like page tables, though. In all extreme cases you'll find that 90% of kernel memory is tied up in just a few data structures. Making a generic infrastructure just to deal with these specific cases is almost certainly overkill. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ - 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/