linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Ingo Molnar <mingo@chiara.csoma.elte.hu>
Cc: "Benjamin C.R. LaHaise" <blah@kvack.org>,
	Rik van Riel <riel@nl.linux.org>,
	Kanoj Sarcar <kanoj@google.engr.sgi.com>,
	Jeff Garzik <jgarzik@mandrakesoft.com>,
	alan@lxorguk.ukuu.org.uk, linux-kernel@vger.rutgers.edu,
	linux-mm@kvack.org, Stephen Tweedie <sct@redhat.com>
Subject: Re: Getting big areas of memory, in 2.3.x?
Date: Sat, 11 Dec 1999 19:56:53 +0000 (GMT)	[thread overview]
Message-ID: <14418.44165.273585.41704@dukat.scot.redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.10.9912100139370.12148-100000@chiara.csoma.elte.hu>

Hi,

On Fri, 10 Dec 1999 01:44:53 +0100 (CET), Ingo Molnar
<mingo@chiara.csoma.elte.hu> said:

> On Thu, 9 Dec 1999, Benjamin C.R. LaHaise wrote:
>> The type of allocation determines what pool memory is allocated from.  
>> Ie nonpagable kernel allocations come from one zone, atomic
>> allocations from another and user from yet another.  ...

> well, this is perfectly possible with the current zone allocator (check
> out how build_zonelists() builds dynamic allocation paths). I dont see
> much point in it though, it might prevent fragmentation to a certain
> degree, but i dont think it is a fair use of memory resources. (i'm pretty
> sure the atomic zone would stay unused most of the time) 

Don't use static zones then.

Something I talked about with Linus a while back was to separate memory
into 4MB or 16MB zones, and do allocation not from individual zones but
from zone lists.  Then you just keep track of two lists of zones: one
which contains zones which are known to have been used for non-pagable
allocations, and another in which all allocations are pagable.  

The pagable-allocation zone family can always be used for large
allocations: you just select a contiguous region of pages which aren't
currently being used by the contiguous allocator, and page them out (or
relocate them to a different zone if you prefer).

If this is only needed by device initialisation, the relocation doesn't
have to be fast.  A dumb, brute-force search (such as is already done by
sys_swapoff()) will do fine.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

  parent reply	other threads:[~1999-12-11 19:56 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-12-09  1:03 Jeff Garzik
1999-12-09  2:28 ` Alan Cox
1999-12-09  2:45   ` Jeff Garzik
1999-12-09  5:22     ` Oliver Xymoron
1999-12-09 12:25     ` Ingo Molnar
1999-12-09 20:24       ` Jeff Garzik
1999-12-09 20:31         ` Kanoj Sarcar
1999-12-09 20:39           ` Rik van Riel
1999-12-09 20:54             ` Kanoj Sarcar
1999-12-09 23:21               ` Ingo Molnar
1999-12-09 22:27                 ` Kanoj Sarcar
1999-12-09 23:16             ` Ingo Molnar
1999-12-09 23:09               ` Benjamin C.R. LaHaise
1999-12-10  0:44                 ` Ingo Molnar
1999-12-10  0:18                   ` William J. Earl
1999-12-11 19:56                   ` Stephen C. Tweedie [this message]
1999-12-10 12:21               ` Rik van Riel
1999-12-10 13:42                 ` Ingo Molnar
1999-12-10 18:04                   ` William J. Earl
1999-12-09 20:50           ` William J. Earl
1999-12-09 23:15         ` Ingo Molnar
1999-12-09 22:13           ` William J. Earl
1999-12-09 22:26             ` Alan Cox
1999-12-09 23:42               ` William J. Earl
1999-12-09 23:50                 ` Alan Cox
1999-12-10  0:30                   ` William J. Earl
1999-12-10  0:37                     ` Alan Cox
1999-12-10  4:19                   ` Oliver Xymoron
1999-12-10 10:14                   ` Thomas Sailer
1999-12-09 23:24             ` Ingo Molnar
1999-12-09 22:33               ` Jeff Garzik
1999-12-09 23:32               ` Rogier Wolff
1999-12-09 23:44                 ` JF Martinez
1999-12-10  0:52                   ` Ingo Molnar
1999-12-09 23:46                 ` Andi Kleen
1999-12-10 13:52       ` Stephen C. Tweedie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=14418.44165.273585.41704@dukat.scot.redhat.com \
    --to=sct@redhat.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=blah@kvack.org \
    --cc=jgarzik@mandrakesoft.com \
    --cc=kanoj@google.engr.sgi.com \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --cc=mingo@chiara.csoma.elte.hu \
    --cc=riel@nl.linux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox