Re: [PATCH] mm: Mark idle page tracking as BROKEN

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 15, 2021 at 8:55 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
>
> On Tue, Jun 15, 2021 at 09:41:37AM +0200, David Hildenbrand wrote:
> > On 12.06.21 02:07, Matthew Wilcox (Oracle) wrote:
> >
> > I might be missing something important, so some questions/comments
> >
> > > In discussion with other MM developers around how idle page tracking
> > > should be fixed for transparent huge pages, several expressed the opinion
> > > that it should be removed as it is inefficient at accomplishing the
> > > job that it is supposed to, and we have better mechanisms (eg uffd) for
> > > accomplishing the same goals these days.
> >
> > 1. A link to that discussion would be nice. I am missing some important
> > details in this patch description.
>
> It was on the phone in our bi-weekly THP call.  As I recall, those
> present were Kirill, Yu Zhao, William Kucharski, Zi Yan, Vlastimil Babka.
> Song Liu sent apologies, and I think Mike Kravetz had a conflict.
>
> > 2. "should be fixed for transparent huge pages" -- has it always been like
> > this or has the behavior changed at some point? Do the semantics, and how
> > the feature is getting used, clearly identify this case that needs fixing as
> > something that really has to be fixed? Or was it always like that and
> > actually expected to work like that ("semtantics")?
>
> I don't know.  I asked the others on the call and the answer I got was
> essentially "Just delete it".
>
> I'm kind of hoping the others speak up.

I listed a couple of things when acking this patch. Being broken is
not a problem as long as there are users who care about it. What made
me think such users may not exist is that nobody ever complained about
those things until we stumbled on them -- I'm not insisting on
deleting this feature, just clarifying why I thought so.

The real question is how well we want to support it. My understanding,
based on the previous discussion, is "as-is". That is we simply follow
the current "semantics" when converting it to using folios.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux