linux-kernel - Re: [PATCH v1 2/2] mm: mTHP stats for pagecache folio allocations

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]

Message-ID: <cdee4c58-49aa-4746-a6cc-8ef833f2322e@redhat.com>
Date: Wed, 17 Jul 2024 12:03:44 +0200
From: David Hildenbrand <david@...hat.com>
To: Ryan Roberts <ryan.roberts@....com>, Lance Yang <ioworker0@...il.com>,
 Baolin Wang <baolin.wang@...ux.alibaba.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Hugh Dickins
 <hughd@...gle.com>, Jonathan Corbet <corbet@....net>,
 "Matthew Wilcox (Oracle)" <willy@...radead.org>,
 Barry Song <baohua@...nel.org>, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org
Subject: Re: [PATCH v1 2/2] mm: mTHP stats for pagecache folio allocations

>>>>>
>>>>> But today, controls and stats are exposed for:
>>>>>
>>>>>      anon:
>>>>>        min order: 2
>>>>>        max order: PMD_ORDER
>>>>>      anon-shmem:
>>>>>        min order: 2
>>>>>        max order: PMD_ORDER
>>>>>      tmpfs-shmem:
>>>>>        min order: PMD_ORDER
>>>>>        max order: PMD_ORDER
>>>>>      file:
>>>>>        min order: Nothing yet (this patch proposes 1)
>>>>>        max order: Nothing yet (this patch proposes MAX_PAGECACHE_ORDER)
>>>>>
>>>>> So I think there is definitely a bug for shmem where the minimum order control
>>>>> should be order-1 but its currently order-2.
>>>>
>>>> Maybe, did not play with that yet. Likely order-1 will work. (although probably
>>>> of questionable use :) )
>>>
>>> You might have to expand on why its of "questionable use". I'd assume it has the
>>> same amount of value as using order-1 for regular page cache pages? i.e. half
>>> the number of objects to manage for the same amount of memory.
>>
>> order-1 was recently added for the pagecache to get some device setups running
>> (IIRC, where we cannot use order-0, because device blocksize > PAGE_SIZE).
>>
>> You might be right about "half the number of objects", but likely just going for
>> order-2, order-3, order-4 ... for shmem might be even better. And simply falling
>> back to order-0 when you cannot get the larger orders.
> 
> Sure, but then you're into the territory of baking in policy. Remember that
> originally I was only interested in 64K but the concensus was to expose all the
> sizes. Same argument applies to 8K; expose it and let others decide policy.

I don't disagree. The point I'm trying to make is that there was so far 
there was no strong evidence that it is really required. Support for the 
pagecache had a different motivation for these special devices.

But again, I agree that we should just make it consistent and allow for 
it. :)

-- 
Cheers,

David / dhildenb