From: Vladimir Davydov <vdavydov@parallels.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org
Subject: Re: [LSF/MM TOPIC ATTEND]
Date: Wed, 7 Jan 2015 11:58:28 +0300 [thread overview]
Message-ID: <20150107085828.GA2110@esperanza> (raw)
In-Reply-To: <20150106161435.GF20860@dhcp22.suse.cz>
On Tue, Jan 06, 2015 at 05:14:35PM +0100, Michal Hocko wrote:
[...]
> And as a memcg co-maintainer I would like to also discuss the following
> topics.
> - We should finally settle down with a set of core knobs exported with
> the new unified hierarchy cgroups API. I have proposed this already
> http://marc.info/?l=linux-mm&m=140552160325228&w=2 but there is no
> clear consensus and the discussion has died later on. I feel it would
> be more productive to sit together and come up with a reasonable
> compromise between - let's start from the begining and keep useful and
> reasonable features.
>
> - kmem accounting is seeing a lot of activity mainly thanks to Vladimir.
> He is basically the only active developer in this area. I would be
> happy if he can attend as well and discuss his future plans in the
> area. The work overlaps with slab allocators and slab shrinkers so
> having people familiar with these areas would be more than welcome
One more memcg related topic that is worth discussing IMO:
- On global memory pressure we walk over all memory cgroups and scan
pages from each of them. Since there can be hundreds or even
thousands of memory cgroups, such a walk can be quite expensive,
especially if the cgroups are small so that to reclaim anything from
them we have to descend to a lower scan priority. The problem is
augmented by offline memory cgroups, which now can be dangling for
indefinitely long time.
That's why I think we should work out a better algorithm for the
memory reclaimer. May be, we could rank memory cgroups somehow (by
their age, memory consumption?) and try to scan only the top ranked
cgroup during a reclaimer run. This topic is also very close to the
soft limit reclaim improvements, which Michal has been working on for
a while.
Thanks,
Vladimir
--
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:[~2015-01-07 8:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-06 16:14 [LSF/MM TOPIC ATTEND] Michal Hocko
2015-01-06 23:27 ` Greg Thelen
2015-01-07 14:28 ` Michal Hocko
2015-01-07 18:54 ` Greg Thelen
2015-01-07 19:00 ` Greg Thelen
2015-01-14 21:27 ` Andrea Arcangeli
2015-01-15 14:06 ` Michal Hocko
2015-01-15 20:58 ` Andrea Arcangeli
2015-01-07 8:58 ` Vladimir Davydov [this message]
2015-01-07 14:38 ` Michal Hocko
2015-01-08 8:33 ` Vladimir Davydov
2015-01-08 9:09 ` Michal Hocko
2015-02-02 8:37 ` [LSF/MM TOPIC ATTEND] - THP benefits Vlastimil Babka
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=20150107085828.GA2110@esperanza \
--to=vdavydov@parallels.com \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mhocko@suse.cz \
/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.