From: "Stephen C. Tweedie" <sct@redhat.com>
To: Manfred Spraul <masp0008@stud.uni-sb.de>
Cc: "Stephen C. Tweedie" <sct@redhat.com>, linux-mm@kvack.org
Subject: Re: Large memory system
Date: Thu, 11 Feb 1999 11:12:11 GMT [thread overview]
Message-ID: <199902111112.LAA02474@dax.scot.redhat.com> (raw)
In-Reply-To: <005001be5517$e06903e0$c80c17ac@clmsdev>
Hi,
On Wed, 10 Feb 1999 18:02:32 +0100, "Manfred Spraul"
<masp0008@stud.uni-sb.de> said:
> This was not intended as a solution, but as a new idea:
> - the memory > 1 GB is allocated one page at a time.
> - some 'struct page' fields are useless for high memory.
> - if someone who is not prepared to handle high memory finds such a page,
> the computer will crash anyway.
> - high memory needs bounce buffers, so a special if(highmem()) is
> required.
All of this is already in the design.
> ---> no need to use mem_map, add an independant array for high_mem.
No, it makes no sense at all to do this, because you'd have to
implement two separate page caches if you wanted both low-mem and
high-mem cached pages. It makes far, far more sense to simply expand
mem_map.
> The advantage is that you can add new fields to such an array (e.g. true
> LRU for a cache), without causing problems in the remaining kernel.
That's really not a problem. As long as we never hand out a high-mem
page to the kernel unless the kernel explicitly asks for one (for
anonymous pages or page cache), the kernel can never get so confused
anyway.
> If you restrict the remaining memory to unshared pages (i.e. no COW), then
> the implementation should be really simple:
There is no reason to make this restriction, COW is dead easy.
--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
next prev parent reply other threads:[~1999-02-11 11:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-02-10 17:02 Large memory system Manfred Spraul
1999-02-11 11:12 ` Stephen C. Tweedie [this message]
-- strict thread matches above, loose matches on Subject: below --
1999-02-08 20:33 Manfred Spraul
1999-02-10 14:25 ` Stephen C. Tweedie
1999-01-30 13:36 Daniel Blakeley
1999-01-30 17:00 ` Benjamin C.R. LaHaise
1999-02-08 11:24 ` Stephen C. Tweedie
1999-02-08 15:31 ` Eric W. Biederman
1999-02-09 22:57 ` Stephen C. Tweedie
1999-02-01 15:59 ` Rik van Riel
1999-02-08 11:22 ` 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=199902111112.LAA02474@dax.scot.redhat.com \
--to=sct@redhat.com \
--cc=linux-mm@kvack.org \
--cc=masp0008@stud.uni-sb.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.