linux-kernel - Re: [PATCH v2 3/4] mm: add find_alloc_contig

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] [day] [month] [year] [list]

Date:   Mon, 28 May 2018 15:12:09 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Reinette Chatre <reinette.chatre@...el.com>,
        Mike Kravetz <mike.kravetz@...cle.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org
Cc:     Michal Hocko <mhocko@...nel.org>,
        Christopher Lameter <cl@...ux.com>,
        Guy Shattah <sguy@...lanox.com>,
        Anshuman Khandual <khandual@...ux.vnet.ibm.com>,
        Michal Nazarewicz <mina86@...a86.com>,
        David Nellans <dnellans@...dia.com>,
        Laura Abbott <labbott@...hat.com>, Pavel Machek <pavel@....cz>,
        Dave Hansen <dave.hansen@...el.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2 3/4] mm: add find_alloc_contig_pages() interface

On 05/23/2018 08:07 PM, Reinette Chatre wrote:
> On 5/23/2018 4:18 AM, Vlastimil Babka wrote:
>> On 05/22/2018 06:41 PM, Reinette Chatre wrote:
>>> Currently the Cache Pseudo-Locking allocations are order based because I
>>> assumed it was required by the allocator. The contiguous regions needed
>>> by Cache Pseudo-Locking will not always be order based - instead it is
>>> based on the granularity of the cache allocation. One example is a
>>> platform with 55MB L3 cache that can be divided into 20 equal portions.
>>> To support Cache Pseudo-Locking on this platform we need to be able to
>>> allocate contiguous regions at increments of 2816KB (the size of each
>>> portion). In support of this example platform regions needed would thus
>>> be 2816KB, 5632KB, 8448KB, etc.
>>
>> Will there be any alignment requirements for these allocations e.g. for
>> minimizing conflict misses?
> 
> Two views on the usage of the allocated memory are: On the user space
> side, the kernel memory is mapped to userspace (using remap_pfn_range())
> and thus need to be page aligned. On the kernel side the memory is
> loaded into the cache and it is here where the requirement originates
> for it to be contiguous. The memory being contiguous reduces the
> likelihood of physical addresses from the allocated memory mapping to
> the same cache line and thus cause cache evictions of memory we are
> trying to load into the cache.

Hi, yeah that's what I've been thinking, and I guess page alignment is
enough for that after all. I'm just not used to cache sizes and ways
that are not power of two :)

> I hope I answered your question, if not, please let me know which parts
> I missed and I will try again.

Thanks!

Vlastimil

> Reinette
>