From: Tejun Heo <tj@kernel.org>
To: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Konstantin Khebnikov <khlebnikov@yandex-team.ru>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
cgroups@vger.kernel.org, Roman Gushchin <klamm@yandex-team.ru>,
Jan Kara <jack@suse.cz>, Dave Chinner <david@fromorbit.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 3/6] memcg: track shared inodes with dirty pages
Date: Thu, 15 Jan 2015 14:08:40 -0500 [thread overview]
Message-ID: <20150115190840.GD28195@htj.dyndns.org> (raw)
In-Reply-To: <CALYGNiPY2K6F+OFoCV5XShrXaQOiyGXreR=4TC=Mp7axTiF0YQ@mail.gmail.com>
Hello,
On Thu, Jan 15, 2015 at 11:04:49PM +0400, Konstantin Khlebnikov wrote:
> I know. Absolutely accurate per-page solution looks too complicated for me.
> Is there any real demand for accurate handling dirty set in shared inodes?
> Doing whole accounting in per-inode basis makes life so much easier.
Ah, yeah, patch #3 arrived in isolation, so I thought it was part of
something completely different. I definitely thought about doing it
per-inode too (and also requiring memcg to attribute pages according
to its inode rather than individual pages). I'll look into the
patchset and try to identify the pros and cons of our approaches.
Thanks.
--
tejun
next prev parent reply other threads:[~2015-01-15 19:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-15 18:49 [PATCHSET RFC 0/6] memcg: inode-based dirty-set controller Konstantin Khebnikov
2015-01-15 18:49 ` [PATCH 1/6] memcg: inode-based dirty and writeback pages accounting Konstantin Khebnikov
2015-01-15 18:49 ` [PATCH 2/6] memcg: dirty-set limiting and filtered writeback Konstantin Khebnikov
2015-01-15 18:49 ` [PATCH 3/6] memcg: track shared inodes with dirty pages Konstantin Khebnikov
2015-01-15 18:55 ` Tejun Heo
2015-01-15 19:04 ` Konstantin Khlebnikov
2015-01-15 19:08 ` Tejun Heo [this message]
2015-01-15 18:49 ` [PATCH 4/6] percpu_ratelimit: high-performance ratelimiting counter Konstantin Khebnikov
2015-01-15 18:49 ` [PATCH 5/6] delay-injection: resource management via procrastination Konstantin Khebnikov
2015-01-15 18:49 ` [PATCH 6/6] memcg: filesystem bandwidth controller Konstantin Khebnikov
2015-01-16 9:37 ` [PATCHSET RFC 0/6] memcg: inode-based dirty-set controller Jan Kara
2015-01-16 12:33 ` Konstantin Khlebnikov
2015-01-16 14:25 ` Jan Kara
2015-01-29 1:21 ` Tejun Heo
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=20150115190840.GD28195@htj.dyndns.org \
--to=tj@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=khlebnikov@yandex-team.ru \
--cc=klamm@yandex-team.ru \
--cc=koct9i@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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).