linux-kernel - Re: [PATCH v2 3/5] mm: shmem: add large folio support for tmpfs

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: <5ed3c225-e77e-4d1b-be73-3027a1be1080@redhat.com>
Date: Fri, 15 Nov 2024 14:48:33 +0100
From: David Hildenbrand <david@...hat.com>
To: Baolin Wang <baolin.wang@...ux.alibaba.com>, akpm@...ux-foundation.org,
 hughd@...gle.com
Cc: willy@...radead.org, wangkefeng.wang@...wei.com, 21cnbao@...il.com,
 ryan.roberts@....com, ioworker0@...il.com, da.gomez@...sung.com,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/5] mm: shmem: add large folio support for tmpfs


>>>            return BIT(HPAGE_PMD_ORDER);
>>
>> Why not force-enable all orders (of course, respecting
>> MAX_PAGECACHE_ORDER and possibly VMA)?
> 
> The ‘force’ option will affect the tmpfs mmap()'s huge allocation, which
> I intend to handle in a separate patch as we discussed. Additionally,
> for the huge page allocation of tmpfs mmap(), I am also considering the
> readahead approach for the pagecache.

Okay, we can change this later. Likely force/deny are a blast from the 
past either way.

[...]

>>> +
>>> +        order = highest_order(within_size_orders);
>>> +        while (within_size_orders) {
>>> +            aligned_index = round_up(index + 1, 1 << order);
>>> +            i_size = max(write_end, i_size_read(inode));
>>> +            i_size = round_up(i_size, PAGE_SIZE);
>>> +            if (i_size >> PAGE_SHIFT >= aligned_index)
>>> +                return within_size_orders;
>>> +
>>> +            order = next_order(&within_size_orders, order);
>>> +        }
>>>            fallthrough;
>>>        case SHMEM_HUGE_ADVISE:
>>>            if (vm_flags & VM_HUGEPAGE)
>>
>> I think the point here is that "write" -> no VMA -> vm_flags == 0 -> no
>> code changes needed :)
> 
> Yes. Currently the fadvise() have no HUGEPAGE handling, so I will drop
> the 'fadvise' in the doc.

Interesting that we documented it :)

-- 
Cheers,

David / dhildenb