From: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
To: Rik van Riel <riel@conectiva.com.br>
Cc: "Richard B. Johnson" <root@chaos.analogic.com>,
Linux kernel <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: kmalloc() allocation.
Date: Tue, 31 Oct 2000 11:48:51 +0100 [thread overview]
Message-ID: <20001031114851.D7204@nightmaster.csn.tu-chemnitz.de> (raw)
In-Reply-To: <Pine.LNX.4.21.0010301439080.16609-100000@duckman.distro.conectiva>; from riel@conectiva.com.br on Mon, Oct 30, 2000 at 02:40:16PM -0200
On Mon, Oct 30, 2000 at 02:40:16PM -0200, Rik van Riel wrote:
> > There are 256 megabytes of SDRAM available. I don't think it's
> > reasonable that a 1/2 megabyte allocation would fail, especially
> > since it's the first module being installed.
> If you write the defragmentation code for the VM, I'll
> be happy to bump up the limit a bit ...
Should become easier once we start doing physical page scannings.
We could record physical continous freeable areas on the fly
then. If someone asks for them later, we recheck whether they
still exists and free (inactive_clean) or remap (active or
inactive_dirty) the whole area, whether they are used or not.
This could still be improved by using up smallest fit areas
first for kmalloc() based on these areas.
But beware: We just have a good hint here, which needs to be
rechecked every time we allocate such areas to become
guarantee.
Rik: What do you think about this (physical cont. area cache) for 2.5?
Regards
Ingo Oeser
--
Feel the power of the penguin - run linux@your.pc
<esc>:x
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next parent reply other threads:[~2000-10-31 10:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.3.95.1001030104956.735A-100000@chaos.analogic.com>
[not found] ` <Pine.LNX.4.21.0010301439080.16609-100000@duckman.distro.conectiva>
2000-10-31 10:48 ` Ingo Oeser [this message]
2000-10-31 13:35 ` Rik van Riel
2000-10-31 13:59 ` Richard B. Johnson
2000-10-31 15:17 ` Ingo Oeser
2000-10-31 16:11 ` Rik van Riel
2000-10-31 18:22 ` Ingo Oeser
2000-10-31 14:43 ` afei
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=20001031114851.D7204@nightmaster.csn.tu-chemnitz.de \
--to=ingo.oeser@informatik.tu-chemnitz.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@conectiva.com.br \
--cc=root@chaos.analogic.com \
/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