Re: Bug: Discontigmem virt_to_page() [Alpha,ARM,Mips64?]

From: David Mosberger (davidm@napali.hpl.hp.com)
Date: Fri May 03 2002 - 18:52:58 EST


[Looks like this buffer was laying dormant in my Emacs and never sent.
 Hence the delay... ;-) ]

>>>>> On Thu, 2 May 2002 10:20:11 +1000, Anton Blanchard <anton@samba.org> said:

>> so ia64 is one of those archs with a ram layout with huge holes
>> in the middle of the ram of the nodes? I'd be curious to know
>> what's the hardware advantage of designing the ram layout in such
>> a way, compared to all other numa archs that I deal with. Also if
>> you know other archs with huge holes in the middle of the ram of
>> the nodes I'd be curious to know about them too. thanks for the
>> interesting info!

>> From arch/ppc64/kernel/iSeries_setup.c:

  Anton> * The iSeries may have very large memories ( > 128 GB ) and
  Anton> a partition * may get memory in "chunks" that may be anywhere
  Anton> in the 2**52 real * address space. The chunks are 256K in
  Anton> size.

  Anton> Also check out CONFIG_MSCHUNKS code and see why I'd love to
  Anton> see a generic solution to this problem.

Me too. HP's zx1 platform also has a rather giant hole above the 1GB
boundary. I don't know the exact reasons for this hole, but it's
related to the fact that (many) PCI devices need <4GB memory.

The current solution for zx1 is to place the mem_map in virtual
memory. This obviously increases TLB pressure when touching lots of
mem_map[] entries randomly, but I haven't really seen any benchmarks
so far (real or artificial) where this has a signifcant performance
effect. The nice part of this approach is that it is a rather general
solution, provided the kernel's page-table mapped address space is
sufficiently big.

        --david
-
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 May 07 2002 - 22:00:21 EST