On Fri 31-07-20 09:50:04, Yafang Shao wrote:

On Thu, Jul 30, 2020 at 7:26 PM Michal Hocko [off-list ref] wrote:

quoted

On Tue 28-07-20 03:40:32, Yafang Shao wrote:

quoted

Sometimes we use memory.force_empty to drop pages in a memcg to work
around some memory pressure issues. When we use force_empty, we want the
pages can be reclaimed ASAP, however force_empty reclaims pages as a
regular reclaimer which scans the page cache LRUs from DEF_PRIORITY
priority and finally it will drop to 0 to do full scan. That is a waste
of time, we'd better do full scan initially in force_empty.

Do you have any numbers please?

Unfortunately the number doesn't improve obviously, while it is
directly proportional to the numbers of total pages to be scanned.

Your changelog claims an optimization and that should be backed by some
numbers. It is true that reclaim at a higher priority behaves slightly
and subtly differently but that urge for even more details in the
changelog.

But then I notice that force_empty will try to write dirty pages, that
is not expected by us, because this behavior may be dangerous in the
production environment.

I do not understand your claim here. Direct reclaim doesn't write dirty
page cache pages directly. And it is even less clear why that would be
dangerous if it did.

What do you think introducing per memcg drop_cache ?

I do not like the global drop_cache and per memcg is not very much
different. This all shouldn't be really necessary because we do have
means to reclaim memory in a memcg.
-- 
Michal Hocko
SUSE Labs