On Mon, 14 Jun 2021 13:49:26 +0000 SeongJae Park <sj38.park@xxxxxxxxx> wrote: > From: SeongJae Park <sjpark@xxxxxxxxx> > > Hello Matthew, > > On Sat, 12 Jun 2021 01:07:14 +0100 "Matthew Wilcox (Oracle)" <willy@xxxxxxxxxxxxx> wrote: > > > 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. > > I think the THP case[1] is an intended behavior[2]. Could you please share a > link to the discussion or a detailed summary if possible? > > > > > 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. > > Amazon Linux is also using it[3], for DAMON[4]. In detail, DAMON doesn't use > Idle Page Tracking but PG_Idle in kernel space, to avoid interfering the > reclaim logic[5]. So, I'm ok with removing the Idle Page Tracking user space > interface, but gonna be opposed to removing PG_Idle. > > Nevertheless, the interference is not a real problem to DAMON, as DAMON is > aimed to provide just a reasonable quality of the monitoring, rather than > strict correctness. Hence, if people think the interference is also not a > problem for the reclaim logic (after all, it does nothing unless sysadmin > manually turns it on in runtime, and can be turned off at anytime), I would > simply update DAMON code to don't use PG_Idle, add warnings in the doc, and > wouldn't be opposed to this change. Couldn't the DAMON patchset simply re-add PG_Idle? Perhaps with a new name which is more appropriate to the DAMON usage?
