Hello, On Mon, Jan 06, 2014 at 11:08:26AM -0800, Laura Abbott wrote: > 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. When you send formal patch, please include things you mentioned in the description rather than simple "This did not scale for multiple holes of memory however" to justify your motivation and please include number you got from this patch because it's mainly performance enhance patch but doesn't include any number(yeb, you sent it as RFC so I don't care now) so that it could make easy to judge that we need this patch or not compared to adding complexity. Thanks. > > Thanks, > Laura > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by The Linux Foundation > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@xxxxxxxxx. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a> -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>