Anton Blanchard wrote:
> > more than 256LV available in LVM], a sane partitioning requires you to
> > have at least a partition for /usr large 1 giga, depends what you're
> > doing of course, but requiring sane partitioning it's an admin problem
> > not a kernel problem IMHO).
> Its not a NUMA machine, its one that allows shared processor logical
> partitions. While I would prefer the hypervisor to give each partition
> a nice memory map (and internally maintain a mapping to real memory)
> it does not. I can imagine if the machine has been up for many months
> memory could become very fragmented.
> Also when we do hotplug memory support will discontigmem be able to
> efficiently handle memory turning up all over the place in the memory
On this type of partitioned system where ppc64 runs, there is not much
administration that could be done to help the problem. As Anton
mentioned, when the system has been up for a long time, and memory has
been moving between partitions which support dynamic memory movement, it
is assured that memory will become very fragmented. As more partitions
on these systems become available, and resources migrate more freely,
the problem will get worse.
Whether this management from kernel to hardware addresses is done in the
hypervisor layer or the OS, the same overhead exists, given todays
hardware structure for PowerPC servers anyway. In todays ppc64
implementation, we just use an array to map from what the kernel sees as
its address space to what is put in the hardware page table and I/O
translation tables, thus not requiring any changes in independant code.
This does consume some storage, but the highly fragmented nature of our
platform memory drives this decision. I would like to see that data
structure decision left to the archs as different platform design points
may lead to different mapping decisions.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.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:14 EST