From: Tejun Heo <tj@kernel.org> To: Konstantin Khlebnikov <koct9i@gmail.com> Cc: Greg Thelen <gthelen@google.com>, Konstantin Khlebnikov <khlebnikov@yandex-team.ru>, Johannes Weiner <hannes@cmpxchg.org>, Michal Hocko <mhocko@suse.cz>, Cgroups <cgroups@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Jan Kara <jack@suse.cz>, Dave Chinner <david@fromorbit.com>, Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@infradead.org>, Li Zefan <lizefan@huawei.com>, Hugh Dickins <hughd@google.com> Subject: Re: [RFC] Making memcg track ownership per address_space or anon_vma Date: Wed, 11 Feb 2015 16:46:50 -0500 [thread overview] Message-ID: <20150211214650.GA11920@htj.duckdns.org> (raw) In-Reply-To: <CALYGNiMm2VajBx0Y+XtLJ8860JS-GHfuSXQrBt32Wt0K7QpH0A@mail.gmail.com> Hello, On Thu, Feb 12, 2015 at 12:22:34AM +0300, Konstantin Khlebnikov wrote: > > Yeah, available memory to the matching memcg and the number of dirty > > pages in it. It's gonna work the same way as the global case just > > scoped to the cgroup. > > That might be a problem: all dirty pages accounted to cgroup must be > reachable for its own personal writeback or balanace-drity-pages will be > unable to satisfy memcg dirty memory thresholds. I've done accounting Yeah, it would. Why wouldn't it? > for per-inode owner, but there is another option: shared inodes might be > handled differently and will be available for all (or related) cgroup > writebacks. I'm not following you at all. The only reason this scheme can work is because we exclude persistent shared write cases. As the whole thing is based on that assumption, special casing shared inodes doesn't make any sense. Doing things like allowing all cgroups to write shared inodes without getting memcg on-board almost immediately breaks pressure propagation while making shared writes a lot more attractive and increasing implementation complexity substantially. Am I missing something? > Another side is that reclaimer now (mosly?) never trigger pageout. > Memcg reclaimer should do something if it finds shared dirty page: > either move it into right cgroup or make that inode reachable for > memcg writeback. I've send patch which marks shared dirty inodes > with flag I_DIRTY_SHARED or so. It *might* make sense for memcg to drop pages being dirtied which don't match the currently associated blkcg of the inode; however, again, as we're basically declaring that shared writes aren't supported, I'm skeptical about the usefulness. Thanks. -- tejun
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org> To: Konstantin Khlebnikov <koct9i@gmail.com> Cc: Greg Thelen <gthelen@google.com>, Konstantin Khlebnikov <khlebnikov@yandex-team.ru>, Johannes Weiner <hannes@cmpxchg.org>, Michal Hocko <mhocko@suse.cz>, Cgroups <cgroups@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Jan Kara <jack@suse.cz>, Dave Chinner <david@fromorbit.com>, Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@infradead.org>, Li Zefan <lizefan@huawei.com>, Hugh Dickins <hughd@google.com> Subject: Re: [RFC] Making memcg track ownership per address_space or anon_vma Date: Wed, 11 Feb 2015 16:46:50 -0500 [thread overview] Message-ID: <20150211214650.GA11920@htj.duckdns.org> (raw) In-Reply-To: <CALYGNiMm2VajBx0Y+XtLJ8860JS-GHfuSXQrBt32Wt0K7QpH0A@mail.gmail.com> Hello, On Thu, Feb 12, 2015 at 12:22:34AM +0300, Konstantin Khlebnikov wrote: > > Yeah, available memory to the matching memcg and the number of dirty > > pages in it. It's gonna work the same way as the global case just > > scoped to the cgroup. > > That might be a problem: all dirty pages accounted to cgroup must be > reachable for its own personal writeback or balanace-drity-pages will be > unable to satisfy memcg dirty memory thresholds. I've done accounting Yeah, it would. Why wouldn't it? > for per-inode owner, but there is another option: shared inodes might be > handled differently and will be available for all (or related) cgroup > writebacks. I'm not following you at all. The only reason this scheme can work is because we exclude persistent shared write cases. As the whole thing is based on that assumption, special casing shared inodes doesn't make any sense. Doing things like allowing all cgroups to write shared inodes without getting memcg on-board almost immediately breaks pressure propagation while making shared writes a lot more attractive and increasing implementation complexity substantially. Am I missing something? > Another side is that reclaimer now (mosly?) never trigger pageout. > Memcg reclaimer should do something if it finds shared dirty page: > either move it into right cgroup or make that inode reachable for > memcg writeback. I've send patch which marks shared dirty inodes > with flag I_DIRTY_SHARED or so. It *might* make sense for memcg to drop pages being dirtied which don't match the currently associated blkcg of the inode; however, again, as we're basically declaring that shared writes aren't supported, I'm skeptical about the usefulness. Thanks. -- tejun -- 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-02-11 21:46 UTC|newest] Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-01-30 4:43 [RFC] Making memcg track ownership per address_space or anon_vma Tejun Heo 2015-01-30 4:43 ` Tejun Heo 2015-01-30 5:55 ` Greg Thelen 2015-01-30 5:55 ` Greg Thelen 2015-01-30 6:27 ` Tejun Heo 2015-01-30 6:27 ` Tejun Heo 2015-01-30 16:07 ` Tejun Heo 2015-01-30 16:07 ` Tejun Heo 2015-01-30 16:07 ` Tejun Heo 2015-02-02 19:26 ` Konstantin Khlebnikov 2015-02-02 19:26 ` Konstantin Khlebnikov 2015-02-02 19:46 ` Tejun Heo 2015-02-02 19:46 ` Tejun Heo 2015-02-03 23:30 ` Greg Thelen 2015-02-03 23:30 ` Greg Thelen 2015-02-04 10:49 ` Konstantin Khlebnikov 2015-02-04 10:49 ` Konstantin Khlebnikov 2015-02-04 17:15 ` Tejun Heo 2015-02-04 17:15 ` Tejun Heo 2015-02-04 17:58 ` Konstantin Khlebnikov 2015-02-04 17:58 ` Konstantin Khlebnikov 2015-02-04 18:28 ` Tejun Heo 2015-02-04 18:28 ` Tejun Heo 2015-02-04 18:28 ` Tejun Heo 2015-02-04 17:06 ` Tejun Heo 2015-02-04 17:06 ` Tejun Heo 2015-02-04 23:51 ` Greg Thelen 2015-02-04 23:51 ` Greg Thelen 2015-02-04 23:51 ` Greg Thelen 2015-02-05 13:15 ` Tejun Heo 2015-02-05 13:15 ` Tejun Heo 2015-02-05 22:05 ` Greg Thelen 2015-02-05 22:05 ` Greg Thelen 2015-02-05 22:25 ` Tejun Heo 2015-02-05 22:25 ` Tejun Heo 2015-02-05 22:25 ` Tejun Heo 2015-02-06 0:03 ` Greg Thelen 2015-02-06 0:03 ` Greg Thelen 2015-02-06 14:17 ` Tejun Heo 2015-02-06 14:17 ` Tejun Heo 2015-02-06 23:43 ` Greg Thelen 2015-02-06 23:43 ` Greg Thelen 2015-02-07 14:38 ` Tejun Heo 2015-02-07 14:38 ` Tejun Heo 2015-02-07 14:38 ` Tejun Heo 2015-02-11 2:19 ` Tejun Heo 2015-02-11 2:19 ` Tejun Heo 2015-02-11 2:19 ` Tejun Heo 2015-02-11 7:32 ` Jan Kara 2015-02-11 7:32 ` Jan Kara 2015-02-11 7:32 ` Jan Kara 2015-02-11 18:28 ` Greg Thelen 2015-02-11 18:28 ` Greg Thelen 2015-02-11 18:28 ` Greg Thelen 2015-02-11 20:33 ` Tejun Heo 2015-02-11 20:33 ` Tejun Heo 2015-02-11 21:22 ` Konstantin Khlebnikov 2015-02-11 21:22 ` Konstantin Khlebnikov 2015-02-11 21:22 ` Konstantin Khlebnikov 2015-02-11 21:46 ` Tejun Heo [this message] 2015-02-11 21:46 ` Tejun Heo 2015-02-11 21:57 ` Konstantin Khlebnikov 2015-02-11 21:57 ` Konstantin Khlebnikov 2015-02-11 21:57 ` Konstantin Khlebnikov 2015-02-11 22:05 ` Tejun Heo 2015-02-11 22:05 ` Tejun Heo 2015-02-11 22:05 ` Tejun Heo 2015-02-11 22:15 ` Konstantin Khlebnikov 2015-02-11 22:15 ` Konstantin Khlebnikov 2015-02-11 22:15 ` Konstantin Khlebnikov 2015-02-11 22:30 ` Tejun Heo 2015-02-11 22:30 ` Tejun Heo 2015-02-12 2:10 ` Greg Thelen 2015-02-12 2:10 ` Greg Thelen
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=20150211214650.GA11920@htj.duckdns.org \ --to=tj@kernel.org \ --cc=axboe@kernel.dk \ --cc=cgroups@vger.kernel.org \ --cc=david@fromorbit.com \ --cc=gthelen@google.com \ --cc=hannes@cmpxchg.org \ --cc=hch@infradead.org \ --cc=hughd@google.com \ --cc=jack@suse.cz \ --cc=khlebnikov@yandex-team.ru \ --cc=koct9i@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=lizefan@huawei.com \ --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: linkBe 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.