On Sat, 12 Feb 2000, Linus Torvalds wrote:
>Alternatively, use the same "highmem" support for it that x86 uses for
That's exactly the basic of I planned to do for 2.3.x and what I am
partially just doing in:
ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.14/bigmem-2.2.14-8.gz
(and in the 2.2.1[34]aa* patches) to support 2T of RAM on alpha.
Additionaly in 2.3.x I can take advantage of the bigmem capable
ll_rw_block layer and of the in progress pci-mmu work to allocate page
cache and buffer cache (yes also buffer cache since it's not a 32bit arch
that needs kmap) all over the memory without doing bounces for the I/O
(using a per blk_dev bitflag to skip the create_bounces in the updated
drivers) and by allocating skb all over the place in new network drivers
adding a bitflag in the allocating GFP mask for the updated drivers.
The two bitflags I mentioned can be trivially dropped in 2.5.0 doing the
breakage at _that_ time and without any constraint for 2.4.0 as far I can
tell.
With the updated drivers shm, userspace, cache and network buffers will
all live all over 2giga with my design and with no bounces for the I/O
will happen. The drivers not uptodate won't break but they will simply run
slower in the blockdevice case and in the network case the skb will stay
on the low 2giga.
I can't see any pressure in the low 2giga with my design. Can you see any
problem with that?
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:23 EST