Re: [RFC PATCHv3 00/11] Intermix Lowmem and vmalloc

From: Laura Abbott
Date: Mon Jan 06 2014 - 14:08:31 EST


On 1/3/2014 11:31 PM, Minchan Kim wrote:
Hello,

On Fri, Jan 03, 2014 at 02:08:52PM -0800, Laura Abbott wrote:
On 1/3/2014 10:23 AM, Dave Hansen wrote:
On 01/02/2014 01:53 PM, Laura Abbott wrote:
The goal here is to allow as much lowmem to be mapped as if the block of memory
was not reserved from the physical lowmem region. Previously, we had been
hacking up the direct virt <-> phys translation to ignore a large region of
memory. This did not scale for multiple holes of memory however.

How much lowmem do these holes end up eating up in practice, ballpark?
I'm curious how painful this is going to get.


In total, the worst case can be close to 100M with an average case
around 70M-80M. The split and number of holes vary with the layout
but end up with 60M-80M one hole and the rest in the other.

One more thing I'd like to know is how bad direct virt <->phys tranlsation
in scale POV and how often virt<->phys tranlsation is called in your worload
so what's the gain from this patch?

Thanks.


With one hole we did

#define __phys_to_virt(phys)
phys >= mem_hole_end ? mem_hole : normal

We had a single global variable to check for the bounds and to do something similar with multiple holes the worst case would be O(number of holes). This would also all need to be macroized. Detection and accounting for these holes in other data structures (e.g. ARM meminfo) would be increasingly complex and lead to delays in bootup. The error/sanity checking for bad memory configurations would also be messier. Non-linear lowmem mappings also make debugging more difficult.

virt <-> phys translation is used on hot paths in IOMMU mapping so we want to keep virt <-> phys as fast as possible and not have to walk an array of addresses every time.

Thanks,
Laura

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/