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.

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")?

For example, just like for softdirty tracking, an over-indication might 
be just fine. More extreme, I think idle tracking can actually deal with 
an under-indication, if it's actually used for minor performance 
improvements (just like with DAEMON). Again, this should be clarified in 
this patch description.

Because I read "This information can be useful for estimating the 
workload’s working set size, which, in turn, can be taken into account 
when configuring the workload parameters, setting memory cgroup limits, 
or deciding where to place the workload within a compute cluster." -- 
which doesn't sound like it has to be 100% correct in all of the cases.

And "Since the idle memory tracking feature is based on the memory 
reclaimer logic, it only works with pages that are on an LRU list, other 
pages are silently ignored. That means it will ignore a user memory page 
if it is isolated, but since there are usually not many of them, it 
should not affect the overall result noticeably. In order not to stall 
scanning of the idle page bitmap, locked pages may be skipped too", so 
there are already special cases to deal with.

3. I don't see how the "better mechanisms" can actually be used to 
accomplish the same goal. You state "uffd", however, I don't see a way 
to actually achieve the same goal using uffd. In MISSING mode, you would 
have to zap/discard page content to get an access notification. in WP 
mode you really cannot catch reads.

Mark the feature as BROKEN for now and we can remove it entirely in a
few months if nobody complains.  It is not enabled by Android, ChromeOS,
Debian, Fedora or SUSE.  Red Hat enabled it with RHEL-8.1 and UEK followed
suit, but I have been unable to find why RHEL enabled it.

My fellow RH people tell me that we enabled in RHEL7 on customer demand 
and consequently enabled it in RHEL8.

To me it feels like we might be removing a feature that is working just 
as expected because the semantics might not be 100% clear to everybody 
involved. Of course, I might be wrong, that's why I'm asking.

I'd actually vote for documenting what's happening, just like we do for 
locked pages and !LRU pages ... unless there is really something heavily 
broken.

-- 
Thanks,

David / dhildenb