Hello
Quoted 3 lines · Benjamin C.R. LaHaise
I think someone created patches that make a ramdisk out of the really high memory. Try doing a search of the linux-kernel archives -- I remember seeing it withing the past 3 or 4 months. Hope this helps!
I wrote that patch, but I abandoned it because I think that the performance would be inacceptable: the data is first cached in the buffer cache, and later moved into high memory, and if you access the data it's moved back. I think that the memmove() calls would slow down the system considerably.
If you need the patch I can send it to you.
But I have a new idea: what about replacing the current 'shm' implementation with a high memory aware implementation.
* use high memory if high memory is available. We only need a simple bitmap for the high-mem. max_mapnr remains 1 or 2 GB, page_map is not extended.
* if you have more than 2 Gb memory, then you don't want that the system starts to swap out. So there is no need to support swap for that memory. This means: no double buffering etc required.
* I haven't yet read the new Xeon page table extentions,
but perhaps we could support up to 64 GB memory without changing the
rest of the OS (Intel could write such a driver for Windows NT,
I'm sure this is possible for Linux, too).
* it's very easy for the user mode programmers, no new interfaces.
I think that this implementation would required only a few hundred lines.
What do you think about this?
Regards,
Manfred
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
Quoted 1 line · Manfred Spraul
If you need the patch I can send it to you.
=) The most memory any of my machines have is 64 megs. It would be nice if more developers had systems with 4 gigs of memory...
Quoted 8 lines
But I have a new idea: what about replacing the current 'shm' implementation with a high memory aware implementation.
* it's very easy for the user mode programmers, no new interfaces.
I think that this implementation would required only a few hundred lines.
What do you think about this?
The implementation I saw Stephen post about is actually even better: add a bit to page->flags to indicate that the memory is HIGH memory, which only gets returned by get_free_page() if the caller inclues a GFP_HIGH_OKAY flag. Then, these pages can be used to fill in anonymous user mappings and shared memory. Presto chango, maybe a couple of hundred line patch and you've got support for 4GB on intel, albeit with restrictions. Then the Xeon 36 bit page tables are a simple extension from there.
-ben
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
Hi,
Quoted 4 lines · Manfred Spraul
* I haven't yet read the new Xeon page table extentions, but perhaps we could support up to 64 GB memory without changing the
rest of the OS (Intel could write such a driver for Windows NT,
I'm sure this is possible for Linux, too).
NT's VLM support only gives you access to the high memory if you use a special API. We plan on supporting clean access to all of physical memory quite transparently for Linux, without any such restrictions.
--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
Quoted 5 lines · Stephen C. Tweedie
Hi,
On Fri, 30 Apr 1999 18:12:21 +0200, "Manfred Spraul" <[email protected]> said:
Quoted 8 lines
Quoted 4 lines
* I haven't yet read the new Xeon page table extentions, but perhaps we could support up to 64 GB memory without changing the
rest of the OS (Intel could write such a driver for Windows NT,
I'm sure this is possible for Linux, too).NT's VLM support only gives you access to the high memory if you use a special API. We plan on supporting clean access to all of physical memory quite transparently for Linux, without any such restrictions.
Not even the restriction that a single process cannot use more than 4GB-something?
-Andi
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
Hi,
On Wed, 1 Jan 1997 16:29:19 +0100, [email protected] said:
^^^^^^^^^^^^^^^
??? Check your clocks!
Quoted 8 lines · Stephen C. Tweedie
Quoted 4 lines
NT's VLM support only gives you access to the high memory if you use a special API. We plan on supporting clean access to all of physical memory quite transparently for Linux, without any such restrictions.
Not even the restriction that a single process cannot use more than 4GB-something?
The high memory support will have no new restrictions visible to the user. The existing 3GB virtual address space limit will not be changed.
--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/