On Sun, Jul 28, 2002 at 02:40:05AM +0200, Daniel Phillips wrote:
> There are two elephants in the bathtub: the mem_map array, which holds a few
> bytes of state information for each physical page in the system, and page
> tables, neither of which are swapped or pruned in any way. We are now
> beginning to suffer pretty badly because of this, on certain high end
> configurations. The problem is, these structures have to keep track of much
> more than just the kernel memory. The former has to have entries for all of
> the high memory pages (not addressable within the kernel's normal virtual
> address space) and the latter has to keep track of pages mapped into every
> task in the system, in other words, a virtually unlimited amount of memory
> (pun intended). Solutions are being pursued. Paging page tables to swap is
> one of the solutions being considered, though nobody has gone so far as to
> try it yet. An easier solution is to place page tables in high memory, and a
> patch for this exists. There is also work being done on page table sharing.
sizeof(mem_map) is a crippling issue for 32-bit machines. Something needs
to be done and fast, but it looks like most of the programmer resources
that would otherwise be there to attack the issue are tied up with even
more severe problems preventing even smaller machines from working well.
Hopefully those can be dealt with swiftly enough before Halloween.
Cheers,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:27 EST