From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753861AbbGBBLK (ORCPT ); Wed, 1 Jul 2015 21:11:10 -0400 Received: from mail-qk0-f172.google.com ([209.85.220.172]:36212 "EHLO mail-qk0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752416AbbGBBLA (ORCPT ); Wed, 1 Jul 2015 21:11:00 -0400 Date: Wed, 1 Jul 2015 21:10:56 -0400 From: Tejun Heo To: Jan Kara Cc: axboe@kernel.dk, linux-kernel@vger.kernel.org, hch@infradead.org, hannes@cmpxchg.org, linux-fsdevel@vger.kernel.org, vgoyal@redhat.com, lizefan@huawei.com, cgroups@vger.kernel.org, linux-mm@kvack.org, mhocko@suse.cz, clm@fb.com, fengguang.wu@intel.com, david@fromorbit.com, gthelen@google.com, khlebnikov@yandex-team.ru Subject: Re: [PATCH 22/51] writeback: add {CONFIG|BDI_CAP|FS}_CGROUP_WRITEBACK Message-ID: <20150702011056.GC26440@mtj.duckdns.org> References: <1432329245-5844-1-git-send-email-tj@kernel.org> <1432329245-5844-23-git-send-email-tj@kernel.org> <20150630093751.GH7252@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150630093751.GH7252@quack.suse.cz> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Jan. On Tue, Jun 30, 2015 at 11:37:51AM +0200, Jan Kara wrote: > Hum, you later changed this to use a per-sb flag instead of a per-fs-type > flag, right? We could do it as well here but OK. The commits were already in stable branch at that point and landed in mainline during this merge window, so I'm afraid the review points will have to be addressed as additional patches. > One more question - what does prevent us from supporting CGROUP_WRITEBACK > for all bdis capable of writeback? I guess the reason is that currently > blkcgs are bound to request_queue and we have to have blkcg(s) for > CGROUP_WRITEBACK to work, am I right? But in principle tracking writeback > state and doing writeback per memcg doesn't seem to be bound to any device > properties so we could do that right? The main issue is that cgroup should somehow know how the processes are mapped to the underlying IO layer - the IO domain should somehow be defined. We can introduce an intermediate abstraction which maps to blkcg and whatever other cgroup controllers which may define cgroup IO domains but given that such cases would be fairly niche, I think we'd be better off making those corner cases represent themselves using blkcg rather than introducing an additional layer. Thanks. -- tejun