[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aYY3tZmsIQnT0b3V@casper.infradead.org>
Date: Fri, 6 Feb 2026 18:49:25 +0000
From: Matthew Wilcox <willy@...radead.org>
To: "David Hildenbrand (Arm)" <david@...nel.org>
Cc: xu.xin16@....com.cn, akpm@...ux-foundation.org,
chengming.zhou@...ux.dev, hughd@...gle.com, wang.yaxin@....com.cn,
yang.yang29@....com.cn, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: ksm: initialize rmap values directly and make them const
On Fri, Feb 06, 2026 at 07:09:56PM +0100, David Hildenbrand (Arm) wrote:
> On 2/6/26 18:34, David Hildenbrand (Arm) wrote:
> > On 2/6/26 16:29, Matthew Wilcox wrote:
> > > On Fri, Feb 06, 2026 at 03:22:54PM +0800, xu.xin16@....com.cn wrote:
> > > > make them const to make code more robust. Besides, since KSM
> > > > folios are always
> > > > order-0, so folio_nr_pages(KSM folio) is always 1, so the line:
> > > >
> > > > "pgoff_end = pgoff_start + folio_nr_pages(folio) - 1;"
> > > >
> > > > becomes directly:
> > > >
> > > > "pgoff_end = pgoff_start;"
> > >
> > > How do you know KSM folios will always be order 0? I don't. NAK this
> > > change.
> >
> > Once that changes we can revisit. ACK from me stands.
>
> And just to elaborate a bit: I don't see support for > 0 happening any time
> soon, and it will require significant changes that I am not even sure we
> would want to maintain upstream :)
OK, you're the KSM maintainer. There doesn't seem to be anywhere else
in the KSM code which handles large folios, so this is just removing
code that was recently added?
Powered by blists - more mailing lists