From: Neil Sun <neilsun@yunify.com>
To: Michal Hocko <mhocko@suse.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/vmscan.c: drop_slab_node with task's memcg
Date: Tue, 6 Apr 2021 22:34:02 +0800 [thread overview]
Message-ID: <d21f3b10-0c39-211f-dc45-e81c8da5dd9d@yunify.com> (raw)
In-Reply-To: <YGxIVDXw7wtBytIg@dhcp22.suse.cz>
On 2021/4/6 19:39, Michal Hocko wrote:
> On Tue 06-04-21 19:30:22, Neil Sun wrote:
>> On 2021/4/6 15:21, Michal Hocko wrote:
>>>
>>> You are changing semantic of the existing user interface. This knob has
>>> never been memcg aware and it is supposed to have a global impact. I do
>>> not think we can simply change that without some users being surprised
>>> or even breaking them.
>>
>> Yes, do you think add new interface to sysfs is a good way? such as
>> /sys/fs/cgroup/memory/lxc/i-vbe1u8o7/memory.kmem.drop_caches
>
> There were other attempts to add a memcg specific alternative to
> drop_caches. A lack of a strong usecase has been a reason that no such
> attempt has been merged until now. drop_caches is a problematic
> interface because it is really coarse and people have learned to (ab)use
> it to workaround problem rather than fix them properly.
>
> What is your usecase?
>
We have some lxc containers running on the server, when mysqld running
backup jobs in the container, page cache will grow up and eat up all
unused memory in the container, then some new jobs come, we can see that
tasks are busy on allocing memory with reclaiming, so we want to drop
page cache after mysql backup job for individual container, it will
speed up allocing memory when new jobs come.
This patch only drop slab cache but not page cache, this can be the
first step if people really need this interface.
---
Neil
next prev parent reply other threads:[~2021-04-06 14:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-02 10:38 [PATCH] mm/vmscan.c: drop_slab_node with task's memcg Neil Sun
2021-04-02 14:38 ` kernel test robot
2021-04-02 14:50 ` kernel test robot
2021-04-06 7:21 ` Michal Hocko
[not found] ` <4dba277d-e497-5c34-0e68-fd2283585de2@yunify.com>
2021-04-06 11:39 ` Michal Hocko
2021-04-06 14:34 ` Neil Sun [this message]
2021-04-06 14:39 ` Michal Hocko
2021-04-06 15:12 ` Neil Sun
2021-04-06 17:38 ` Michal Hocko
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=d21f3b10-0c39-211f-dc45-e81c8da5dd9d@yunify.com \
--to=neilsun@yunify.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).