From: "Manfred Spraul" <masp0008@stud.uni-sb.de>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: linux-mm@kvack.org
Subject: Re: Large memory system
Date: Wed, 10 Feb 1999 18:02:32 +0100 [thread overview]
Message-ID: <005001be5517$e06903e0$c80c17ac@clmsdev> (raw)
>The primary reason for adding more memory is for process anonymous
>pages, not for cache, so this is really of limited value on its own.
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.
---> no need to use mem_map, add an independant array for high_mem.
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.
If you restrict the remaining memory to unshared pages (i.e. no COW), then
the implementation should be really simple:
* all page-in's go to normal memory (i.e. < 1 GB) (swap cache compatible)
* if try_to_swap_out() want's to discard a page, it is first moved to high
memory.
(this break's any COW links.)
* if <shrink_highmem> decides that a page should be discarded, then the page
is removed from the vma, a bounce buffer is created, written out & added to
the swap cache.
I'm sure that this could be extended to COW pages, but I haven't yet
understood the COW implementation :=)
Regards,
Manfred
--
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 reply other threads:[~1999-02-10 17:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-02-10 17:02 Manfred Spraul [this message]
1999-02-11 11:12 ` Large memory system Stephen C. Tweedie
-- 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='005001be5517$e06903e0$c80c17ac@clmsdev' \
--to=masp0008@stud.uni-sb.de \
--cc=linux-mm@kvack.org \
--cc=sct@redhat.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 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.