linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Zi Yan <ziy@nvidia.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	Pankaj Raghav <p.raghav@samsung.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Mike Rapoport <rppt@kernel.org>,
	Ryan Roberts <ryan.roberts@arm.com>,
	Michal Hocko <mhocko@suse.com>, Lance Yang <lance.yang@linux.dev>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	Dev Jain <dev.jain@arm.com>, Barry Song <baohua@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Nico Pache <npache@redhat.com>, Vlastimil Babka <vbabka@suse.cz>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Jens Axboe <axboe@kernel.dk>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	mcgrof@kernel.org, gost.dev@samsung.com, kernel@pankajraghav.com,
	tytso@mit.edu
Subject: Re: [RFC v2 0/3] Decoupling large folios dependency on THP
Date: Fri, 27 Feb 2026 21:19:34 +0100	[thread overview]
Message-ID: <65bc73f4-e07c-4ead-9eda-b142e691e110@kernel.org> (raw)
In-Reply-To: <4A89F75A-325B-4FFC-AAB6-07C206844B02@nvidia.com>

On 2/27/26 21:16, Zi Yan wrote:
> On 27 Feb 2026, at 15:10, David Hildenbrand (Arm) wrote:
> 
>> On 2/27/26 16:19, Matthew Wilcox wrote:
>>>
>>> In the Ottawa interpretation, that's true, but I'd prefer not to revisit
>>> this code when transitioning to the New York interpretation.  This is
>>> the NOMMU code after all, and the less time we spend on it, the better.
>>>
>>>
>>> Depending on your point of view, either everything is mapped on nommu,
>>> or nothing is mapped ;-)  In any case, the folio is freshly-allocated
>>> and locked, so there's no chance anybody has mapped it yet.
>>>
>>>
>>> Well, it is, but it's also exactly what we need to do -- frees folios
>>> which are now entirely beyond i_size.  And it's code that's also used on
>>> MMU systems, and the more code that's shared, the better.
>>>
>>>
>>> Right, we could do that.  But that's more code and special code in the
>>> nommu codebase.
>>
>> I guess I'd have to see the frankenstein folio_split() to judge if it is
>> really better :)
>>
>> If it's really just about skipping the unmap+remap the end result would
>> indeed be nice.
> 
> Without unmap+remap, that is just __folio_freeze_and_split_unmapped()? ;)

I'm rather wondering what else we find when we try actually using it :)

-- 
Cheers,

David


      reply	other threads:[~2026-02-27 20:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-06  3:08 Pankaj Raghav
2025-12-06  3:08 ` [RFC v2 1/3] filemap: set max order to be min order if THP is disabled Pankaj Raghav
2025-12-09  7:45   ` Hannes Reinecke
2025-12-09 16:33     ` Pankaj Raghav
2025-12-10  0:38       ` Hannes Reinecke
2025-12-06  3:08 ` [RFC v2 2/3] huge_memory: skip warning if min order and folio order are same in split Pankaj Raghav
2025-12-06  3:08 ` [RFC v2 3/3] blkdev: remove CONFIG_TRANSPARENT_HUGEPAGES dependency for LBS devices Pankaj Raghav
2025-12-09 16:03 ` [RFC v2 0/3] Decoupling large folios dependency on THP Zi Yan
2025-12-10  4:27   ` Matthew Wilcox
2025-12-10 16:37     ` Zi Yan
2025-12-11  7:37       ` Matthew Wilcox
2026-02-27  5:31 ` Matthew Wilcox
2026-02-27  8:45   ` David Hildenbrand (Arm)
2026-02-27 15:19     ` Matthew Wilcox
2026-02-27 20:10       ` David Hildenbrand (Arm)
2026-02-27 20:16         ` Zi Yan
2026-02-27 20:19           ` David Hildenbrand (Arm) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=65bc73f4-e07c-4ead-9eda-b142e691e110@kernel.org \
    --to=david@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=dev.jain@arm.com \
    --cc=gost.dev@samsung.com \
    --cc=kernel@pankajraghav.com \
    --cc=lance.yang@linux.dev \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mcgrof@kernel.org \
    --cc=mhocko@suse.com \
    --cc=npache@redhat.com \
    --cc=p.raghav@samsung.com \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=surenb@google.com \
    --cc=tytso@mit.edu \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox