Path: csiph.com!aioe.org!gothmog.csi.it!bofh.it!news.nic.it!robomod From: Tejun Heo Newsgroups: linux.kernel Subject: Re: [PATCH] block, cgroup: implement policy-specific per-blkcg data Date: Sat, 06 Jun 2015 04:00:02 +0200 Message-ID: References: X-Original-To: Arianna Avanzini Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=JuPV1c/vJugjzII6ShBtFhF0JSFg2KmYhbM463wGYPI=; b=AGHr8nmBKTXpPdjXzX0hp21vur+mm3shxlwtlid5qF9jpWiAspQB1gkxdtg8iO9c7J DqvM/nE7BlcRRufAlAeLyo9a5prqAAZAwa3RoOIMx43vcewx/aFp5lgnR/V761tnd82u aTfHkLdtj+8j9kiNaRXk9a+gm6tiTo73vL/c0sACqut/n4HbI1Eau2yfs5pamY1GrVQc UJMlJZpnCYcO2vqJ6hFrB0JAhLUZ+fqKJikzDMHrBl8jnhGJBZ7/dHEAN+ERWVcWiicO vv/myXvUrBYYxNieMV1Z9kK+H+HgZ3v8H3cc313IHWSgQJNO4ELIwbulG2yOEQG3yFI8 BitQ== X-Received: by 10.70.109.131 with SMTP id hs3mr10355350pdb.40.1433555887953; Fri, 05 Jun 2015 18:58:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: robomod@news.nic.it List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Approved: robomod@news.nic.it Lines: 83 Organization: linux.* mail to news gateway X-Original-Cc: linux-kernel@vger.kernel.org, axboe@kernel.dk, paolo.valente@unimore.it, Jens Axboe X-Original-Date: Sat, 6 Jun 2015 10:58:02 +0900 X-Original-Message-ID: <20150606015802.GB12744@mtj.duckdns.org> X-Original-References: <1433540322-15152-1-git-send-email-avanzini.arianna@gmail.com> X-Original-Sender: linux-kernel-owner@vger.kernel.org Xref: aioe.org linux.kernel:1159816 Hello, On Fri, Jun 05, 2015 at 11:38:42PM +0200, Arianna Avanzini wrote: > The block IO (blkio) controller enables the block layer to provide service > guarantees in a hierarchical fashion. Specifically, service guarantees > are provided by registered request-accounting policies. As of now, a > proportional-share and a throttling policy are available. They are > implemented, respectively, by the CFQ I/O scheduler and the blk-throttle > subsystem. Unfortunately, as for adding new policies, the current > implementation of the block IO controller is only halfway ready to allow > new policies to be plugged in. This commit provides a solution to make > the block IO controller fully ready to handle new policies. > In what follows, we first describe briefly the current state, and then > list the changes made by this commit. > > The throttling policy does not need any per-cgroup information to perform > its task. In contrast, the proportional share policy uses, for each cgroup, > both the weight assigned by the user to the cgroup, and a set of dynamically- > computed weights, one for each device. > > The first, user-defined weight is stored in the blkcg data structure: the > block IO controller allocates a private blkcg data structure for each > cgroup in the blkio cgroups hierarchy (regardless of which policy is active). > In other words, the block IO controller internally mirrors the blkio cgroups > with private blkcg data structures. > > On the other hand, for each cgroup and device, the corresponding dynamically- > computed weight is maintained in the following, different way. For each device, > the block IO controller keeps a private blkcg_gq structure for each cgroup in > blkio. In other words, block IO also keeps one private mirror copy of the blkio > cgroups hierarchy for each device, made of blkcg_gq structures. > Each blkcg_gq structure keeps per-policy information in a generic array of > dynamically-allocated 'dedicated' data structures, one for each registered > policy (so currently the array contains two elements). To be inserted into the > generic array, each dedicated data structure embeds a generic blkg_policy_data > structure. Consider now the array contained in the blkcg_gq structure > corresponding to a given pair of cgroup and device: one of the elements > of the array contains the dedicated data structure for the proportional-share > policy, and this dedicated data structure contains the dynamically-computed > weight for that pair of cgroup and device. > > The generic strategy adopted for storing per-policy data in blkcg_gq structures > is already capable of handling new policies, whereas the one adopted with blkcg > structures is not, because per-policy data are hard-coded in the blkcg > structures themselves (currently only data related to the proportional- > share policy). > > This commit addresses the above issues through the following changes: > . It generalizes blkcg structures so that per-policy data are stored in the same > way as in blkcg_gq structures. > Specifically, it lets also the blkcg structure store per-policy data in a > generic array of dynamically-allocated dedicated data structures. We will > refer to these data structures as blkcg dedicated data structures, to > distinguish them from the dedicated data structures inserted in the generic > arrays kept by blkcg_gq structures. > To allow blkcg dedicated data structures to be inserted in the generic array > inside a blkcg structure, this commit also introduces a new blkcg_policy_data > structure, which is the equivalent of blkg_policy_data for blkcg dedicated > data structures. > . It adds to the blkcg_policy structure, i.e., to the descriptor of a policy, a > cpd_size field and a cpd_init field, to be initialized by the policy with, > respectively, the size of the blkcg dedicated data structures, and the > address of a constructor function for blkcg dedicated data structures. > . It moves the CFQ-specific fields embedded in the blkcg data structure (i.e., > the fields related to the proportional-share policy), into a new blkcg > dedicated data structure called cfq_group_data. > > Signed-off-by: Paolo Valente > Signed-off-by: Arianna Avanzini > Cc: Tejun Heo > Cc: Jens Axboe Acked-by: Tejun Heo Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/