From: Nikolay Borisov <n.borisov-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org>
To: Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Access rules for current->memcg
Date: Fri, 17 Jul 2015 10:16:25 +0300 [thread overview]
Message-ID: <55A8ABC9.7090701@siteground.com> (raw)
In-Reply-To: <20150717071339.GA24787-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
On 07/17/2015 10:13 AM, Michal Hocko wrote:
> On Fri 17-07-15 00:21:51, Nikolay Borisov wrote:
>> On Thu, Jul 16, 2015 at 6:22 PM, Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>> On Thu 16-07-15 18:11:48, Nikolay Borisov wrote:
>>>>
>>>>
>>>> On 07/16/2015 05:59 PM, Michal Hocko wrote:
>>>>> On Thu 16-07-15 16:34:08, Nikolay Borisov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I'd like to ask what are the locking rules when using
>>>>>> mem_cgroup_from_task(current)? Currently I'm doing this under
>>>>>> rcu_read_lock which I believe is sufficient. However, I've seen patches
>>>>>> where reference is obtained via mem_cgroup_from_task and then
>>>>>> css_tryget_online is used on the resulting cgroup?
>>>>>
>>>>> RCU will guarantee that the memcg will not go away. The rest depends on
>>>>> what you want to do with it. If you want to use it outside of RCU you
>>>>> have to take a reference. And then it depends what the memcg is used
>>>>> for - some operations can be done also on the offline memcg.
>>>>>
>>>>> Btw. mem_cgroup_from_task is not the proper interface for you. You
>>>>> really want to do
>>>>> memcg = get_mem_cgroup_from_mm(current->mm)
>>>>> [...]
>>>>> css_put(&memcg)
>>>>
>>>> Unfortunately this function is static, do you think there might be any
>>>> value of a patch that exposes it upstream?
>>>
>>> Ohh, you are right! I thought I made it visible with my recent changes
>>> but nope. There are no external users currently.
>>>
>>> Could you tell us more why it would be useful for you?
>>
>> In my particular use case I have to query the memcg's various counters to expose
>> them to the user in a different way than via the cgroup files
>> (memory.limit_in_bytes etc).
>
> Why is the regular interface not sufficient?
In my particular case I'm interested in playing with the contents of
/proc/meminfo, so that processes running inside a cgroup only see the
the system as defined by the memcg restrictions
next prev parent reply other threads:[~2015-07-17 7:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-16 13:34 Access rules for current->memcg Nikolay Borisov
[not found] ` <55A7B2D0.1030506-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org>
2015-07-16 14:59 ` Michal Hocko
[not found] ` <20150716145902.GA10758-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-07-16 15:11 ` Nikolay Borisov
[not found] ` <55A7C9B4.3010907-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org>
2015-07-16 15:22 ` Michal Hocko
[not found] ` <20150716152239.GA22529-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-07-16 21:21 ` Nikolay Borisov
[not found] ` <CAJFSNy6sLX82+3ZW_COr__pDTd9aSGgL1bjryMKKcVPhEN0F9g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-07-17 7:13 ` Michal Hocko
[not found] ` <20150717071339.GA24787-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-07-17 7:16 ` Nikolay Borisov [this message]
[not found] ` <55A8ABC9.7090701-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org>
2015-07-20 11:17 ` Michal Hocko
[not found] ` <20150720111707.GE1211-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-07-20 11:22 ` Nikolay Borisov
[not found] ` <55ACD9F8.2040802-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org>
2015-07-21 7:48 ` Michal Hocko
[not found] ` <20150721074834.GF11967-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-07-21 9:08 ` Nikolay Borisov
[not found] ` <55AE0C18.5000304-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org>
2015-07-21 9:24 ` Johannes Weiner
2015-07-21 9:48 ` Michal Hocko
[not found] ` <20150721094832.GI11967-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-07-21 10:32 ` Nikolay Borisov
[not found] ` <55AE1FB7.8050107-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org>
2015-07-21 12:25 ` 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=55A8ABC9.7090701@siteground.com \
--to=n.borisov-/ecpmmvkun9plgfmi4vtta@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.