linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ying Han <yinghan@google.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: Balbir Singh <bsingharora@gmail.com>,
	Rik van Riel <riel@redhat.com>, Hugh Dickins <hughd@google.com>,
	Johannes Weiner <hannes@cmpxchg.org>, Mel Gorman <mel@csn.ul.ie>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Pavel Emelyanov <xemul@openvz.org>,
	linux-mm@kvack.org
Subject: Re: memcg: add mlock statistic in memory.stat
Date: Fri, 13 Jan 2012 14:24:15 -0800	[thread overview]
Message-ID: <CALWz4iwRRm9wiAQoY9w6XTOVcR_VQNYo-4jiswPqu9zD9_NgoQ@mail.gmail.com> (raw)
In-Reply-To: <20120112204458.GA10389@tiehlicka.suse.cz>

On Thu, Jan 12, 2012 at 12:44 PM, Michal Hocko <mhocko@suse.cz> wrote:
> On Thu 12-01-12 11:09:58, Ying Han wrote:
>> On Thu, Jan 12, 2012 at 4:54 AM, Michal Hocko <mhocko@suse.cz> wrote:
>> > On Wed 11-01-12 14:41:08, Ying Han wrote:
>> >> We have the nr_mlock stat both in meminfo as well as vmstat system wide, this
>> >> patch adds the mlock field into per-memcg memory stat. The stat itself enhances
>> >> the metrics exported by memcg, especially is used together with "uneivctable"
>> >> lru stat.
>> >
>> > Could you describe when the unevictable has such a different meaning than
>> > mlocked that it is unusable?
>>
>> The unevictable lru includes more than mlock()'d pages ( SHM_LOCK'd
>> etc). Like the following:
>
> Yes, I am aware of that. Maybe I wasn't clear enough in my question. I
> was rather interested _when_ it actually matters for your decisions about
> the setup. Those pages are not evictable anyway.

It is true that we (as kernel) can not do much on those pages as long
as they are unevictable. The mlock stat I am proposing is more useful
for system admin, and sometimes for kernel developers as well. Many
times in the past that we need to read the mlock stat from the
per-container meminfo for different reasons. Sorry I can not give you
a very concrete example, but I do remember it happened a lot.

On the other hand, we do have the ability to read the mlock from
meminfo, and we should add the same visibility to memcg as well.

--Ying

>
>> $ memtoy>shmem shm_400m 400m
>> $ memtoy>map shm_400m 0 400m
>> $ memtoy>touch shm_400m
>> memtoy:  touched 102400 pages in  0.360 secs
>> $ memtoy>slock shm_400m
>> //meantime add some memory pressure.
>>
>> $ memtoy>file /export/hda3/file_512m
>> $ memtoy>map file_512m 0 512m shared
>> $ memtoy>lock file_512m
>>
>> $ cat /dev/cgroup/memory/B/memory.stat
>> mapped_file 956301312
>> mlock 536870912
>> unevictable 956203008
>>
>> Here, mapped_file - mlock = 400M shm_lock'ed pages are included in
>> unevictable stat.
>>
>> Besides, not all mlock'ed pages get to unevictable lru at the first
>> place, and the same for the other way around.
>>
>> Thanks
>>
>> --Ying
>
> --
> Michal Hocko
> SUSE Labs
> SUSE LINUX s.r.o.
> Lihovarska 1060/12
> 190 00 Praha 9
> Czech Republic

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2012-01-13 22:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-11 22:41 Ying Han
2012-01-11 23:17 ` Hugh Dickins
2012-01-11 23:59   ` KAMEZAWA Hiroyuki
2012-01-12  0:50     ` Ying Han
2012-01-12  3:21       ` KAMEZAWA Hiroyuki
2012-01-12 19:13         ` Ying Han
2012-01-13  0:10           ` KAMEZAWA Hiroyuki
2012-01-13 22:27             ` Ying Han
2012-01-12 12:54 ` Michal Hocko
2012-01-12 19:09   ` Ying Han
2012-01-12 20:44     ` Michal Hocko
2012-01-13 22:24       ` Ying Han [this message]

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=CALWz4iwRRm9wiAQoY9w6XTOVcR_VQNYo-4jiswPqu9zD9_NgoQ@mail.gmail.com \
    --to=yinghan@google.com \
    --cc=bsingharora@gmail.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=mhocko@suse.cz \
    --cc=riel@redhat.com \
    --cc=xemul@openvz.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox