From: Shakeel Butt <shakeelb@google.com>
To: Christopher Lameter <cl@linux.com>
Cc: Jan Kara <jack@suse.cz>, Amir Goldstein <amir73il@gmail.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Greg Thelen <gthelen@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Mel Gorman <mgorman@suse.de>, Vlastimil Babka <vbabka@suse.cz>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>, Cgroups <cgroups@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/3] Directed kmem charging
Date: Wed, 21 Feb 2018 12:05:11 -0800 [thread overview]
Message-ID: <CALvZod5e+DUKKvsZwv02SK9r1SXpZApQedvbdvuXm7V5cBAsGA@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1802211155500.13845@nuc-kabylake>
On Wed, Feb 21, 2018 at 9:57 AM, Christopher Lameter <cl@linux.com> wrote:
> On Wed, 21 Feb 2018, Shakeel Butt wrote:
>
>> On Wed, Feb 21, 2018 at 8:09 AM, Christopher Lameter <cl@linux.com> wrote:
>> > Another way to solve this is to switch the user context right?
>> >
>> > Isnt it possible to avoid these patches if do the allocation in another
>> > task context instead?
>> >
>>
>> Sorry, can you please explain what you mean by 'switch the user
>> context'. Is there any example in kernel which does something similar?
>
> See include/linux/task_work.h. One use case is in mntput_no_expire() in
> linux/fs/namespace.c
>
>From what I understand, using task_work will require fanotify/inotify
event handler to allocate memory asynchronously. IMHO the code will be
much more complex if we go through that route.
> Another way is by adding a field 'remote_memcg_to_charge' in
> task_struct and set it before the allocation and in memcontrol.c,
> first check if current->remote_memcg_to_charge is set otherwise use
> the memcg of current. Also if we provide a wrapper to do that for the
> user, there will be a lot less plumbing.
>
> Please let me know if you prefer this approach.
>
What do you think of the above approach. I think the amount and
complexity of code will be much less.
>> > Are there really any other use cases beyond fsnotify?
>> >
>>
>> Another use case I have in mind and plan to upstream is to bind a
>> filesystem mount with a memcg. So, all the file pages (or anon pages
>> for shmem) and kmem (like inodes and dentry) will be charged to that
>> memcg.
>
> The mount logic already uses task_work.h. That may be the approach to
> expand there.
The task_work approach will require that the job is already running at
the time of mount operation. Usually the mount operations are done by
either admin or the control task starting the job and is a part of
setting up the environment. So, there might not be any process running
at the time of mount operation.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2018-02-21 20:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-21 3:00 Shakeel Butt
2018-02-21 3:00 ` [PATCH v2 1/3] mm: memcg: plumbing memcg for kmem cache allocations Shakeel Butt
2018-02-21 3:01 ` [PATCH v2 2/3] mm: memcg: plumbing memcg for kmalloc allocations Shakeel Butt
2018-02-21 3:01 ` [PATCH v2 3/3] fs: fsnotify: account fsnotify metadata to kmemcg Shakeel Butt
2018-02-21 16:35 ` Christopher Lameter
2018-02-22 13:49 ` Michal Hocko
2018-02-22 14:48 ` Jan Kara
2018-02-22 16:44 ` Yang Shi
2018-02-22 19:00 ` Shakeel Butt
2018-02-21 16:09 ` [PATCH v2 0/3] Directed kmem charging Christopher Lameter
2018-02-21 17:18 ` Shakeel Butt
2018-02-21 17:57 ` Christopher Lameter
2018-02-21 20:05 ` Shakeel Butt [this message]
2018-02-22 13:53 ` Jan Kara
2018-02-23 3:16 ` Christopher Lameter
2018-02-21 20:54 ` Andrew Morton
2018-02-22 13:46 ` Jan Kara
2018-02-23 3:19 ` Christopher Lameter
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=CALvZod5e+DUKKvsZwv02SK9r1SXpZApQedvbdvuXm7V5cBAsGA@mail.gmail.com \
--to=shakeelb@google.com \
--cc=akpm@linux-foundation.org \
--cc=amir73il@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=cl@linux.com \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
--cc=vdavydov.dev@gmail.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