All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kefeng Wang <wangkefeng.wang@huawei.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	Christian Brauner <brauner@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Jan Kara <jack@suse.cz>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Lorenzo Stoakes <ljs@kernel.org>, Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Vlastimil Babka <vbabka@kernel.org>,
	<linux-fsdevel@vger.kernel.org>, <linux-mm@kvack.org>
Subject: Re: [PATCH RFC] fs: drop_caches: introduce per-node drop_caches interface
Date: Thu, 9 Apr 2026 16:08:37 +0800	[thread overview]
Message-ID: <dbb92553-58ba-42e1-b7df-b8450bd69d33@huawei.com> (raw)
In-Reply-To: <addP4MKmA8zfSN1o@tiehlicka>



On 4/9/2026 3:06 PM, Michal Hocko wrote:
> On Thu 09-04-26 14:35:03, Kefeng Wang wrote:
>> Add a sysfs interface at /sys/devices/system/node/nodeX/drop_caches
>> to allow dropping caches on a specific NUMA node.
>>
>> The existing global drop_caches mechanism (/proc/sys/vm/drop_caches)
>> operates across all NUMA nodes indiscriminately, causing,
>> - Unnecessary eviction of hot cache on some nodes
>> - Performance degradation for applications with NUMA affinity
>> - Long times spent on large systems with lots of memory
>>
>> By exposing a per-node interface, admistrator can,
>> - Target specific nodes experiencing memory pressure
>> - Preserve cache on unaffected nodes
>> - Perform reclamation with finer granularity
> 
> Quite honestly drop_caches is not the best interface to build any new
> functionality on top of. It has backfired a lot in the past and we have
> tried to make it extra clear that this should be used for debugging
> purposes only. Extending it further sounds like a bad step.


I am not clear about this history of this interface, but some of our
products do use this interface :(

> 
>> One use cases is hot-pluggable NUMA nodes, during hot-remove, simply
>> dropping pagecache is far more efficient than migrating large amounts
>> of pages to other nodes, which also eliminating the risk of accessing
>> potentially faulty memory.
> 
> Does the per-node reclaim interface can help with this by
> any means?

I have also considered this interface. As mentioned above, our product
uses drop_caches, so it is easy to convert to using the per-node
drop_caches interface.

'echo 1 > per-node-dropcaches'  VS 'echo XG swappiness=0 > per-node-reclaim'

To use the reclaim interface, there are two differences,

1) we need to input the reclaim numbers and swappiness, this is not a 
big problem
2) for reclaim, it supports swappiness=max to only reclaim anonymous 
pages, but cannot only reclaim file pages,

So if per-node-drop_caches cannot be accepted, we can consider expanding
the reclaim interface to reclaim file pages?

  parent reply	other threads:[~2026-04-09  8:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-09  6:35 [PATCH RFC] fs: drop_caches: introduce per-node drop_caches interface Kefeng Wang
2026-04-09  7:06 ` Michal Hocko
2026-04-09  7:19   ` Lorenzo Stoakes
2026-04-09  8:21     ` Kefeng Wang
2026-04-09  8:27       ` Lorenzo Stoakes
2026-04-09  8:08   ` Kefeng Wang [this message]
2026-04-09  8:22     ` Michal Hocko
2026-04-09  8:54       ` Kefeng Wang
2026-04-09 10:52         ` Michal Hocko
2026-04-09 12:50           ` Kefeng Wang
2026-04-09 13:00             ` Kefeng Wang
2026-04-09 13:01             ` Michal Hocko
2026-04-09 13:45               ` Kefeng Wang
2026-04-09  8:30     ` Lorenzo Stoakes
2026-04-09 15:16     ` Andrew Morton
2026-04-09 19:41       ` Michal Hocko
2026-04-09 20:39         ` Matthew Wilcox
2026-04-13  8:29 ` kernel test robot
2026-04-13  8:29 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dbb92553-58ba-42e1-b7df-b8450bd69d33@huawei.com \
    --to=wangkefeng.wang@huawei.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=david@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.