From: Michal Hocko <mhocko@suse.cz>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-mm@kvack.org
Subject: [LSF/MM TOPIC] Few things I would like to discuss
Date: Tue, 5 Feb 2013 13:35:15 +0100 [thread overview]
Message-ID: <20130205123515.GA26229@dhcp22.suse.cz> (raw)
Hi,
I would like to discuss the following topics:
* memcg oom should be more sensitive to locked contexts because now
it is possible that a task is sitting in mem_cgroup_handle_oom holding
some other lock (e.g. i_mutex or mmap_sem) up the chain which might
block other task to terminate on OOM so we basically end up in a
deadlock. Almost all memcg charges happen from the page fault path
where we can retry but one class of them happen from
add_to_page_cache_locked and that is a bit more problematic.
* memcg doesn't use PF_MEMALLOC for the targeted reclaim code paths
which asks for stack overflows (and we have already seen those -
e.g. from the xfs pageout paths). The primary problem to use the flag
is that there is no dirty pages throttling and writeback kicked out
for memcg so if we didn't writeback from the reclaim the caller could
be blocked for ever. Memcg dirty accounting is shaping slowly so we
should start thinking about the writeback as well.
* While we are at the memcg dirty pages accounting
(https://lkml.org/lkml/2012/12/25/95). It turned out that the locking
is really nasty (https://lkml.org/lkml/2013/1/2/48). The locking
should be reworked without incurring any penalty on the fast path.
This sounds really challenging.
* I would really like to finally settle down on something wrt. soft
limit reclaim. I am pretty sure Ying would like to discuss this topic
as well so I will not go into details about it. I will post what I
have before the conference so that we can discuss her approach and
what was the primary disagreement the last time. I can go into more
ditails as a follow up if people are interested of course.
* Finally I would like to collect feedback for the mm git tree.
--
Michal Hocko
SUSE Labs
--
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 reply other threads:[~2013-02-05 12:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-05 12:35 Michal Hocko [this message]
2013-02-05 14:13 ` [LSF/MM TOPIC] Few things I would like to discuss Glauber Costa
2013-02-13 0:39 ` Kamezawa Hiroyuki
2013-02-13 3:53 ` [Lsf-pc] " James Bottomley
2013-02-13 8:20 ` Glauber Costa
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=20130205123515.GA26229@dhcp22.suse.cz \
--to=mhocko@suse.cz \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.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;
as well as URLs for NNTP newsgroup(s).