From: "Yang Shi" <yang.s@alibaba-inc.com> To: Michal Hocko <mhocko@kernel.org>, Jan Kara <jack@suse.cz> Cc: amir73il@gmail.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] fs: fsnotify: account fsnotify metadata to kmemcg Date: Tue, 14 Nov 2017 03:10:22 +0800 [thread overview] Message-ID: <10924085-6275-125f-d56b-547d734b6f4e@alibaba-inc.com> (raw) In-Reply-To: <20171109135444.znaksm4fucmpuylf@dhcp22.suse.cz> On 11/9/17 5:54 AM, Michal Hocko wrote: > [Sorry for the late reply] > > On Tue 31-10-17 11:12:38, Jan Kara wrote: >> On Tue 31-10-17 00:39:58, Yang Shi wrote: > [...] >>> I do agree it is not fair and not neat to account to producer rather than >>> misbehaving consumer, but current memcg design looks not support such use >>> case. And, the other question is do we know who is the listener if it >>> doesn't read the events? >> >> So you never know who will read from the notification file descriptor but >> you can simply account that to the process that created the notification >> group and that is IMO the right process to account to. > > Yes, if the creator is de-facto owner which defines the lifetime of > those objects then this should be a target of the charge. > >> I agree that current SLAB memcg accounting does not allow to account to a >> different memcg than the one of the running process. However I *think* it >> should be possible to add such interface. Michal? > > We do have memcg_kmem_charge_memcg but that would require some plumbing > to hook it into the specific allocation path. I suspect it uses kmalloc, > right? Yes. I took a look at the implementation and the callsites of memcg_kmem_charge_memcg(). It looks it is called by: * charge kmem to memcg, but it is charged to the allocator's memcg * allocate new slab page, charge to memcg_params.memcg I think this is the plumbing you mentioned, right? Thanks, Yang >
WARNING: multiple messages have this Message-ID (diff)
From: "Yang Shi" <yang.s@alibaba-inc.com> To: Michal Hocko <mhocko@kernel.org>, Jan Kara <jack@suse.cz> Cc: amir73il@gmail.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] fs: fsnotify: account fsnotify metadata to kmemcg Date: Tue, 14 Nov 2017 03:10:22 +0800 [thread overview] Message-ID: <10924085-6275-125f-d56b-547d734b6f4e@alibaba-inc.com> (raw) In-Reply-To: <20171109135444.znaksm4fucmpuylf@dhcp22.suse.cz> On 11/9/17 5:54 AM, Michal Hocko wrote: > [Sorry for the late reply] > > On Tue 31-10-17 11:12:38, Jan Kara wrote: >> On Tue 31-10-17 00:39:58, Yang Shi wrote: > [...] >>> I do agree it is not fair and not neat to account to producer rather than >>> misbehaving consumer, but current memcg design looks not support such use >>> case. And, the other question is do we know who is the listener if it >>> doesn't read the events? >> >> So you never know who will read from the notification file descriptor but >> you can simply account that to the process that created the notification >> group and that is IMO the right process to account to. > > Yes, if the creator is de-facto owner which defines the lifetime of > those objects then this should be a target of the charge. > >> I agree that current SLAB memcg accounting does not allow to account to a >> different memcg than the one of the running process. However I *think* it >> should be possible to add such interface. Michal? > > We do have memcg_kmem_charge_memcg but that would require some plumbing > to hook it into the specific allocation path. I suspect it uses kmalloc, > right? Yes. I took a look at the implementation and the callsites of memcg_kmem_charge_memcg(). It looks it is called by: * charge kmem to memcg, but it is charged to the allocator's memcg * allocate new slab page, charge to memcg_params.memcg I think this is the plumbing you mentioned, right? Thanks, Yang > -- 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:[~2017-11-13 19:10 UTC|newest] Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-10-27 18:22 [PATCH v2] fs: fsnotify: account fsnotify metadata to kmemcg Yang Shi 2017-10-27 18:22 ` Yang Shi 2017-10-27 18:22 ` Yang Shi 2017-10-28 14:19 ` Amir Goldstein 2017-10-28 14:19 ` Amir Goldstein 2017-10-29 2:39 ` Matthew Wilcox 2017-10-29 2:39 ` Matthew Wilcox 2017-10-30 12:43 ` Jan Kara 2017-10-30 12:43 ` Jan Kara 2017-10-30 16:39 ` Yang Shi 2017-10-30 16:39 ` Yang Shi 2017-10-31 10:12 ` Jan Kara 2017-10-31 10:12 ` Jan Kara 2017-10-31 16:44 ` Yang Shi 2017-10-31 16:44 ` Yang Shi 2017-11-01 15:15 ` Jan Kara 2017-11-01 15:15 ` Jan Kara 2017-11-09 13:54 ` Michal Hocko 2017-11-09 13:54 ` Michal Hocko 2017-11-13 19:10 ` Yang Shi [this message] 2017-11-13 19:10 ` Yang Shi 2017-11-14 9:39 ` Michal Hocko 2017-11-14 9:39 ` Michal Hocko 2017-11-14 17:32 ` Yang Shi 2017-11-14 17:32 ` Yang Shi 2017-11-15 9:31 ` Jan Kara 2017-11-15 9:31 ` Jan Kara 2018-01-19 15:02 ` Shakeel Butt 2018-01-19 15:02 ` Shakeel Butt 2018-01-22 20:31 ` Amir Goldstein 2018-01-22 20:31 ` Amir Goldstein 2018-01-24 10:34 ` Jan Kara 2018-01-24 10:34 ` Jan Kara 2018-01-24 11:12 ` Amir Goldstein 2018-01-24 11:12 ` Amir Goldstein 2018-01-25 1:08 ` Shakeel Butt 2018-01-25 1:08 ` Shakeel Butt 2018-01-25 1:54 ` Al Viro 2018-01-25 1:54 ` Al Viro 2018-01-25 2:15 ` Shakeel Butt 2018-01-25 2:15 ` Shakeel Butt 2018-01-25 7:51 ` Amir Goldstein 2018-01-25 7:51 ` Amir Goldstein 2018-01-25 20:20 ` Shakeel Butt 2018-01-25 20:20 ` Shakeel Butt 2018-01-25 20:36 ` Amir Goldstein 2018-01-25 20:36 ` Amir Goldstein 2018-02-13 6:30 ` Amir Goldstein 2018-02-13 6:30 ` Amir Goldstein 2018-02-13 6:30 ` Amir Goldstein 2018-02-13 21:10 ` Shakeel Butt 2018-02-13 21:10 ` Shakeel Butt 2018-02-13 21:10 ` Shakeel Butt 2018-02-13 21:54 ` Amir Goldstein 2018-02-13 21:54 ` Amir Goldstein 2018-02-13 22:20 ` Shakeel Butt 2018-02-13 22:20 ` Shakeel Butt 2018-02-14 1:59 ` Shakeel Butt 2018-02-14 1:59 ` Shakeel Butt 2018-02-14 1:59 ` Shakeel Butt 2018-02-14 8:38 ` Amir Goldstein 2018-02-14 8:38 ` Amir Goldstein 2018-02-19 13:50 ` Jan Kara 2018-02-19 13:50 ` Jan Kara 2018-02-19 19:07 ` Amir Goldstein 2018-02-19 19:07 ` Amir Goldstein 2018-02-20 12:43 ` Jan Kara 2018-02-20 12:43 ` Jan Kara 2018-02-20 19:20 ` Shakeel Butt 2018-02-20 19:20 ` Shakeel Butt 2018-02-20 20:30 ` Amir Goldstein 2018-02-20 20:30 ` Amir Goldstein 2018-02-14 9:00 ` Amir Goldstein 2018-02-14 9:00 ` Amir Goldstein 2018-02-14 9:00 ` Amir Goldstein
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=10924085-6275-125f-d56b-547d734b6f4e@alibaba-inc.com \ --to=yang.s@alibaba-inc.com \ --cc=amir73il@gmail.com \ --cc=jack@suse.cz \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@kernel.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: linkBe 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.