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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 06 Jan 2014 11:08:26 -0800
From:	Laura Abbott <lauraa@...eaurora.org>
To:	Minchan Kim <minchan@...nel.org>
CC:	Dave Hansen <dave@...1.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kyungmin Park <kmpark@...radead.org>, linux-mm@...ck.org,
	Russell King <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCHv3 00/11] Intermix Lowmem and vmalloc

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/