Rough notes from Kernel Consolidation meeting

Arnd Bergmann arnd at arndb.de
Thu Sep 23 18:48:48 BST 2010


On Thursday 23 September 2010 19:03:42 Catalin Marinas wrote:
> On Thu, 2010-09-23 at 16:15 +0100, Arnd Bergmann wrote:
> > On Thursday 23 September 2010, Nicolas Pitre wrote:
> > > >  This highmem topic comes from the fact that highmem will be needed in
> > > >  the period of time between now and LPAE where we have boards with lots
> > > >  of memory but we can't address it all without highmem (unless we want
> > > >  to revisit the 3g/1g split, but I personally think not).
> > >
> > > Note that LPAE does require highmem to be useful.  The only way highmem
> > > could be avoided is to move to a 64-bit architecture.
> > 
> > Right, I'd even say LPAE can only make things worse because people
> > will stick even more memory into their systems, most of which then
> > becomes highmem.
> 
> If you really need so much memory, it's more efficient to have LPAE
> +highmem than a swap device. The problem is if the OS doesn't need so
> much memory but it is available, Linux tries to allocate from highmem
> first. What could help is a different zone fall back mechanism trying to
> allocate from lowmem up to a certain threshold.
> 
> Another option would be to use the highmem for hosting a swap via some
> form of ramdisk or slram/phram.
> 
> Yet another option is some dynamic memory hotplug based on the amount of
> spare memory you've got.

Right. Unfortunately all of these ideas depend a lot on the workload
you actually want to run. For the general case, highmem is probably the
best we can do.

If you know you have at most 2GB of memory, the 2g/2g split is also
an interesting option for many workloads.

Yet another variant of your phram swap is to use compressed swap,
whatever that is called nowadays.

> > We might be able to use MMU features to implement a 4G/4G split, which
> > lets us use 3GB physical RAM or more (depending on vmalloc and I/O sizes)
> > without highmem, but can have an even higher cost by significantly
> > slowing down uaccess.
> 
> It would be tricky to create temporary mappings for uaccess (and may
> involve get_user_pages or some form of pinning the pages in memory).

That's what I meant with expensive. You end up with get_user turning
into

	get_user_pages_fast()
	kmap_atomic()
	memcpy()
	kunmap_atomic()
	put_page()

The get_user_pages_fast is bad enough, but if you're unfortunate enough
to still require highmem, the kmap_atomic is going to hurt even more.

With a pure 4G/4G split and highmem disabled, it may be worth trying,
but again it will depend on the workload if there is anything to gain here.


	Arnd



More information about the linaro-dev mailing list