[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b0a1b637-cad6-9458-53ab-4f54c2b808c9@oracle.com>
Date: Fri, 9 Jun 2023 13:18:59 -0700
From: Sidhartha Kumar <sidhartha.kumar@...cle.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
akpm@...ux-foundation.org, songmuchun@...edance.com,
mike.kravetz@...cle.com, david@...hat.com, nphamcs@...il.com,
jthoughton@...gle.com
Subject: Re: [PATCH 1/2] mm/filemap: remove hugetlb special casing in
filemap.c
On 6/9/23 1:05 PM, Matthew Wilcox wrote:
> On Fri, Jun 09, 2023 at 12:49:46PM -0700, Sidhartha Kumar wrote:
>> @@ -850,12 +847,9 @@ static inline loff_t folio_file_pos(struct folio *folio)
>>
>> /*
>> * Get the offset in PAGE_SIZE (even for hugetlb folios).
>> - * (TODO: hugetlb folios should have ->index in PAGE_SIZE)
>> */
>> static inline pgoff_t folio_pgoff(struct folio *folio)
>> {
>> - if (unlikely(folio_test_hugetlb(folio)))
>> - return hugetlb_basepage_index(&folio->page);
>> return folio->index;
>> }
>>
>
> Unfortunately, you can't split the patches like this. If somebody's
> running a git bisect for an entirely different problem and lands on the
> boundary between these two patches, they'll have a non-functional kernel
> (at least if they're using hugetlbfs). So these two patches have to be
> combined. Maybe there's another way to split up the patches, but I
> don't immediately see it. Maybe after I read more of them.
While this is under review, should I keep it split so the filemap and
hugetlb parts are separate and easier to review or should I combine
these two patches together for the v2 immediately?
Thanks
Powered by blists - more mailing lists