From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrea Righi Subject: Re: [RFC PATCH 0/3] cgroup: fsio throttle controller Date: Sat, 19 Jan 2019 11:08:27 +0100 Message-ID: <20190119100827.GA1630@xps-13> References: <20190118103127.325-1-righi.andrea@gmail.com> <20190118163530.w5wpzpjkcnkektsp@macbook-pro-91.dhcp.thefacebook.com> <20190118184403.GB1535@xps-13> <20190118194652.gg5j2yz3h2llecpj@macbook-pro-91.dhcp.thefacebook.com> Mime-Version: 1.0 Content-Transfer-Encoding: base64 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=8F9NLQ6kP99EptHHFDvN202g5hUHgqJdJYyjeX/YXZo=; b=qmDXJpodc+pzhJoUOEw4j279PeQ4AAN50Gm2xzZNjxVx9iy2udr4/uKYydWi2hVZks OBWcy8NNrkpwVtv6HeIWleQGLeQUyjzWoul6X4uKQ3+CG3RSEkgaPFdIbFKLBmcVmmU4 kQs1EEbrrkimfrs38N9MdpMpxNVWg+8kxcSxE8ORpi2bQdBdZ2qHkhZRWsckGGYun2Dk 79jR8Btfk5I6HSF9lnIAUsLq8xSU7iK0W+K9FlqKAxwyYIMLmSHQQ8gCM1Znq5gTbCtL P7d8xjlPFkcFC6ex/+21RJaA1jQJ8egHLg3wxAGxWohSz6H9A7y5VPPerDuHGvcaaFSS J9ew== Content-Disposition: inline In-Reply-To: <20190118194652.gg5j2yz3h2llecpj@macbook-pro-91.dhcp.thefacebook.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="macroman" To: Josef Bacik Cc: Tejun Heo , Li Zefan , Johannes Weiner , Jens Axboe , Vivek Goyal , Dennis Zhou , cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org T24gRnJpLCBKYW4gMTgsIDIwMTkgYXQgMDI6NDY6NTNQTSAtMDUwMCwgSm9zZWYgQmFjaWsgd3Jv dGU6Cj4gT24gRnJpLCBKYW4gMTgsIDIwMTkgYXQgMDc6NDQ6MDNQTSArMDEwMCwgQW5kcmVhIFJp Z2hpIHdyb3RlOgo+ID4gT24gRnJpLCBKYW4gMTgsIDIwMTkgYXQgMTE6MzU6MzFBTSAtMDUwMCwg Sm9zZWYgQmFjaWsgd3JvdGU6Cj4gPiA+IE9uIEZyaSwgSmFuIDE4LCAyMDE5IGF0IDExOjMxOjI0 QU0gKzAxMDAsIEFuZHJlYSBSaWdoaSB3cm90ZToKPiA+ID4gPiBUaGlzIGlzIGEgcmVkZXNpZ24g b2YgbXkgb2xkIGNncm91cC1pby10aHJvdHRsZSBjb250cm9sbGVyOgo+ID4gPiA+IGh0dHBzOi8v bHduLm5ldC9BcnRpY2xlcy8zMzA1MzEvCj4gPiA+ID4gCj4gPiA+ID4gSSdtIHJlc3VtaW5nIHRo aXMgb2xkIHBhdGNoIHRvIHBvaW50IG91dCBhIHByb2JsZW0gdGhhdCBJIHRoaW5rIGlzIHN0aWxs Cj4gPiA+ID4gbm90IHNvbHZlZCBjb21wbGV0ZWx5Lgo+ID4gPiA+IAo+ID4gPiA+ID0gUHJvYmxl bSA9Cj4gPiA+ID4gCj4gPiA+ID4gVGhlIGlvLm1heCBjb250cm9sbGVyIHdvcmtzIHJlYWxseSB3 ZWxsIGF0IGxpbWl0aW5nIHN5bmNocm9ub3VzIEkvTwo+ID4gPiA+IChSRUFEcyksIGJ1dCBhIGxv dCBvZiBJL08gcmVxdWVzdHMgYXJlIGluaXRpYXRlZCBvdXRzaWRlIHRoZSBjb250ZXh0IG9mCj4g PiA+ID4gdGhlIHByb2Nlc3MgdGhhdCBpcyB1bHRpbWF0ZWx5IHJlc3BvbnNpYmxlIGZvciBpdHMg Y3JlYXRpb24gKGUuZy4sCj4gPiA+ID4gV1JJVEVzKS4KPiA+ID4gPiAKPiA+ID4gPiBUaHJvdHRs aW5nIGF0IHRoZSBibG9jayBsYXllciBpbiBzb21lIGNhc2VzIGlzIHRvbyBsYXRlIGFuZCB3ZSBt YXkgZW5kCj4gPiA+ID4gdXAgc2xvd2luZyBkb3duIHByb2Nlc3NlcyB0aGF0IGFyZSBub3QgcmVz cG9uc2libGUgZm9yIHRoZSBJL08gdGhhdAo+ID4gPiA+IGlzIGJlaW5nIHByb2Nlc3NlZCBhdCB0 aGF0IGxldmVsLgo+ID4gPiAKPiA+ID4gSG93IHNvPyAgVGhlIHdyaXRlYmFjayB0aHJlYWRzIGFy ZSBwZXItY2dyb3VwIGFuZCBoYXZlIHRoZSBjZ3JvdXAgc3R1ZmYgc2V0Cj4gPiA+IHByb3Blcmx5 LiAgU28gaWYgeW91IGRpcnR5IGEgYnVuY2ggb2YgcGFnZXMsIHRoZXkgYXJlIGFzc29jaWF0ZWQg d2l0aCB5b3VyCj4gPiA+IGNncm91cCwgYW5kIHRoZW4gd3JpdGViYWNrIGhhcHBlbnMgYW5kIGl0 J3MgZG9uZSBpbiB0aGUgd3JpdGViYWNrIHRocmVhZAo+ID4gPiBhc3NvY2lhdGVkIHdpdGggeW91 ciBjZ3JvdXAgYW5kIHRoZW4gdGhhdCBpcyB0aHJvdHRsZWQuICBUaGVuIHlvdSBhcmUgdGhyb3R0 bGVkCj4gPiA+IGF0IGJhbGFuY2VfZGlydHlfcGFnZXMoKSBiZWNhdXNlIHRoZSB3cml0ZW91dCBp cyB0YWtpbmcgbG9uZ2VyLgo+ID4gCj4gPiBSaWdodCwgd3JpdGViYWNrIGlzIHBlci1jZ3JvdXAg YW5kIHNsb3dpbmcgZG93biB3cml0ZWJhY2sgYWZmZWN0cyBvbmx5Cj4gPiB0aGF0IHNwZWNpZmlj IGNncm91cCwgYnV0LCB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgb3RoZXIgcHJvY2Vzc2VzIGZyb20K PiA+IG90aGVyIGNncm91cHMgbWF5IHJlcXVpcmUgdG8gd2FpdCBvbiB0aGF0IHdyaXRlYmFjayB0 byBjb21wbGV0ZSBiZWZvcmUKPiA+IGRvaW5nIEkvTyAoZm9yIGV4YW1wbGUgYW4gZnN5bmMoKSB0 byBhIGZpbGUgc2hhcmVkIGFtb25nIGRpZmZlcmVudAo+ID4gY2dyb3VwcykuIEluIHRoaXMgY2Fz ZSB3ZSBtYXkgZW5kIHVwIGJsb2NraW5nIGNncm91cHMgdGhhdCBzaG91bGRuJ3QgYmUKPiA+IGJs b2NrZWQsIHRoYXQgbG9va3MgbGlrZSBhIHByaW9yaXR5LWludmVyc2lvbiBwcm9ibGVtLiBUaGlz IGlzIHRoZQo+ID4gcHJvYmxlbSB0aGF0IEknbSB0cnlpbmcgdG8gYWRkcmVzcy4KPiAKPiBXZWxs IHRoaXMgY2FzZSBpcyBhIG1pc2NvbmZpZ3VyYXRpb24sIHlvdSBzaG91bGRuJ3QgYmUgc2hhcmlu ZyBmaWxlcyBiZXR3ZWVuCj4gY2dyb3Vwcy4gIEJ1dCBldmVuIGlmIHlvdSBhcmUsIGZzeW5jKCkg aXMgc3luY2hyb25vdXMsIHdlIHNob3VsZCBiZSBnZXR0aW5nIHRoZQo+IGNvbnRleHQgZnJvbSB0 aGUgcHJvY2VzcyBpdHNlbGYgYW5kIHRodXMgc2hvdWxkIGhhdmUgaXRzIG93biBydWxlcyBhcHBs aWVkLgo+IFRoZXJlJ3Mgbm90aGluZyB3ZSBjYW4gZG8gZm9yIG91dHN0YW5kaW5nIElPLCBidXQg dGhhdCBzaG91bGRuJ3QgYmUgdGhhdCBtdWNoLgo+IFRoYXQgd291bGQgbmVlZCB0byBiZSBkZWFs dCB3aXRoIG9uIGEgcGVyLWNvbnRvbGxlciBiYXNpcy4KCk9LLCBmYWlyIHBvaW50LiBXZSBzaG91 bGRuJ3QgYmUgc2hhcmluZyBmaWxlcyBiZXR3ZWVuIGNncm91cHMuCgpJJ20gc3RpbGwgbm90IHN1 cmUgaWYgd2UgY2FuIGhhdmUgc2ltaWxhciBpc3N1ZXMgd2l0aCBtZXRhZGF0YSBJL08gKHRoYXQK bWF5IGludHJvZHVjZSBsYXRlbmNpZXMgbGlrZSB0aGUgc3luYygpIHNjZW5hcmlvKSwgSSBoYXZl IHRvIGludmVzdGlnYXRlCm1vcmUgYW5kIGRvIG1vcmUgdGVzdHMuCgo+IAo+ID4gCj4gPiA+IAo+ ID4gPiBJIGludHJvZHVjZWQgdGhlIGJsa19jZ3JvdXBfY29uZ2VzdGVkKCkgc3R1ZmYgZm9yIHBh dGhzIHRoYXQgaXQncyBub3QgZWFzeSB0bwo+ID4gPiBjbGVhcmx5IHRpZSBJTyB0byB0aGUgdGhp bmcgZ2VuZXJhdGluZyB0aGUgSU8sIHN1Y2ggYXMgcmVhZGFoZWFkIGFuZCBzdWNoLiAgSWYKPiA+ ID4geW91IGFyZSBydW5uaW5nIGludG8gdGhpcyBjYXNlIHRoYXQgbWF5IGJlIHNvbWV0aGluZyB3 b3J0aCB1c2luZy4gIENvdXJzZSBpdAo+ID4gPiBvbmx5IHdvcmtzIGZvciBpby5sYXRlbmN5IG5v dyBidXQgdGhlcmUncyBubyByZWFzb24geW91IGNhbid0IGFkZCBzdXBwb3J0IHRvIGl0Cj4gPiA+ IGZvciBpby5tYXggb3Igd2hhdGV2ZXIuCj4gPiAKPiA+IElJVUMgYmxrX2Nncm91cF9jb25nZXN0 ZWQoKSBpcyB1c2VkIGluIHJlYWRhaGVhZCBJL08gKGFuZCBzd2FwIHdpdGgKPiA+IG1lbWNnKSwg c29tZXRoaW5nIGxpa2UgdGhpczogaWYgdGhlIGNncm91cCBpcyBhbHJlYWR5IGNvbmdlc3RlZCBk b24ndAo+ID4gZ2VuZXJhdGUgZXh0cmEgSS9PIGR1ZSB0byByZWFkYWhlYWQuIEFtIEkgcmlnaHQ/ Cj4gCj4gWWVhaCwgYnV0IHRoYXQncyBqdXN0IGhvdyBpdCdzIGN1cnJlbnRseSB1c2VkLCBpdCBj YW4gYmUgdXNlZCBhbnkgd2hpY2ggd2F5IHdlCj4gZmVlbCBsaWtlLgoKSSB0aGluayBpdCdkIGJl IHZlcnkgaW50ZXJlc3RpbmcgdG8gaGF2ZSB0aGUgcG9zc2liaWxpdHkgdG8gZWl0aGVyCnRocm90 dGxlIEkvTyBiZWZvcmUgd3JpdGViYWNrIG9yIGR1cmluZyB3cml0ZWJhY2suIFJpZ2h0IG5vdyB3 ZSBjYW4gb25seQp0aHJvdHRsZSB3cml0ZWJhY2suIE1heWJlIHdlIGNhbiB0cnkgdG8gaW50cm9k dWNlIHNvbWUga2luZCBvZiBkaXJ0eQpwYWdlIHRocm90dGxpbmcgY29udHJvbGxlciB1c2luZyBi bGtfY2dyb3VwX2Nvbmdlc3RlZCgpLi4uIE9waW5pb25zPwoKPiAKPiA+IAo+ID4gPiAKPiA+ID4g PiAKPiA+ID4gPiA9IFByb3Bvc2VkIHNvbHV0aW9uID0KPiA+ID4gPiAKPiA+ID4gPiBUaGUgbWFp biBpZGVhIG9mIHRoaXMgY29udHJvbGxlciBpcyB0byBzcGxpdCBJL08gbWVhc3VyZW1lbnQgYW5k IEkvTwo+ID4gPiA+IHRocm90dGxpbmc6IEkvTyBpcyBtZWFzdXJlZCBhdCB0aGUgYmxvY2sgbGF5 ZXIgZm9yIFJFQURTLCBhdCBwYWdlIGNhY2hlCj4gPiA+ID4gKGRpcnR5IHBhZ2VzKSBmb3IgV1JJ VEVzLCBhbmQgcHJvY2Vzc2VzIGFyZSBsaW1pdGVkIHdoaWxlIHRoZXkncmUKPiA+ID4gPiBnZW5l cmF0aW5nIEkvTyBhdCB0aGUgVkZTIGxldmVsLCBiYXNlZCBvbiB0aGUgbWVhc3VyZWQgSS9PLgo+ ID4gPiA+IAo+ID4gPiAKPiA+ID4gVGhpcyBpcyB3aGF0IGJsa19jZ3JvdXBfY29uZ2VzdGVkKCkg aXMgbWVhbnQgdG8gYWNjb21wbGlzaCwgSSB3b3VsZCBzdWdnZXN0Cj4gPiA+IGxvb2tpbmcgaW50 byB0aGF0IHJvdXRlIGFuZCBzaW1wbHkgY2hhbmdpbmcgdGhlIGV4aXN0aW5nIGlvIGNvbnRyb2xs ZXIgeW91IGFyZQo+ID4gPiB1c2luZyB0byB0YWtlIGFkdmFudGFnZSBvZiB0aGF0IHNvIGl0IHdp bGwgYWN0dWFsbHkgdGhyb3R0bGUgdGhpbmdzLiAgVGhlbiBqdXN0Cj4gPiA+IHNwcmlua2xlIGl0 IGFyb3VuZCB0aGUgYXJlYXMgd2hlcmUgd2UgaW5kaXJlY3RseSBnZW5lcmF0ZSBJTy4gIFRoYW5r cywKPiA+IAo+ID4gQWJzb2x1dGVseSwgSSBjYW4gcHJvYmFibHkgdXNlIGJsa19jZ3JvdXBfY29u Z2VzdGVkKCkgYXMgYSBtZXRob2QgdG8KPiA+IGRldGVybWluZSB3aGVuIGEgY2dyb3VwIHNob3Vs ZCBiZSB0aHJvdHRsZWQgKGluc3RlYWQgb2YgZG9pbmcgbXkgb3duCj4gPiBJL08gbWVhc3VyaW5n KSwgYnV0IHRvIHByZXZlbnQgdGhlICJzbG93IHdyaXRlYmFjayBzbG93aW5nIGRvd24gb3RoZXIK PiA+IGNncm91cHMiIGlzc3VlIEkgc3RpbGwgbmVlZCB0byBhcHBseSB0aHJvdHRsaW5nIHdoZW4g cGFnZXMgYXJlIGRpcnRpZWQKPiA+IGluIHBhZ2UgY2FjaGUuCj4gCj4gQWdhaW4gdGhpcyBpcyBq dXN0IGEgZnVja3VwIGZyb20gYSBjb25maWd1cmF0aW9uIHN0YW5kIHBvaW50LiAgVGhlIGFyZ3Vt ZW50Cj4gY291bGQgYmUgbWFkZSB0aGF0IHN5bmMoKSBpcyBwcm9iYWJseSBicm9rZW4gaGVyZSwg YnV0IEkgdGhpbmsgdGhlIHJpZ2h0Cj4gc29sdXRpb24gaGVyZSBpcyB0byBqdXN0IHBhc3MgdGhl IGNncm91cCBjb250ZXh0IGFsb25nIHdpdGggdGhlIHdyaXRlYmFjawo+IGluZm9ybWF0aW9uIGFu ZCB1c2UgdGhhdCBpZiBpdCdzIHNldCBpbnN0ZWFkLiAgVGhhbmtzLAoKQWxyaWdodCwgbGV0J3Mg c2tpcCB0aGUgcm9vdCBjZ3JvdXAgZm9yIG5vdy4gSSB0aGluayB0aGUgcG9pbnQgaGVyZSBpcwpp ZiB3ZSB3YW50IHRvIHByb3ZpZGUgc3luYygpIGlzb2xhdGlvbiBhbW9uZyBjZ3JvdXBzIG9yIG5v dC4KCkFjY29yZGluZyB0byB0aGUgbWFucGFnZToKCiAgICAgICBzeW5jKCkgIGNhdXNlcyAgYWxs ICBwZW5kaW5nICBtb2RpZmljYXRpb25zICB0byBmaWxlc3lzdGVtIG1ldGFkYXRhIGFuZCBjYWNo ZWQgZmlsZSBkYXRhIHRvIGJlCiAgICAgICB3cml0dGVuIHRvIHRoZSB1bmRlcmx5aW5nIGZpbGVz eXN0ZW1zLgoKQW5kOgogICAgICAgQWNjb3JkaW5nIHRvIHRoZSBzdGFuZGFyZCBzcGVjaWZpY2F0 aW9uIChlLmcuLCBQT1NJWC4xLTIwMDEpLCBzeW5jKCkgc2NoZWR1bGVzIHRoZSB3cml0ZXMsIGJ1 dAogICAgICAgbWF5ICByZXR1cm4gIGJlZm9yZSAgdGhlIGFjdHVhbCB3cml0aW5nIGlzIGRvbmUu ICBIb3dldmVyIExpbnV4IHdhaXRzIGZvciBJL08gY29tcGxldGlvbnMsIGFuZAogICAgICAgdGh1 cyBzeW5jKCkgb3Igc3luY2ZzKCkgcHJvdmlkZSB0aGUgc2FtZSBndWFyYW50ZWVzIGFzIGZzeW5j IGNhbGxlZCBvbiBldmVyeSBmaWxlIGluIHRoZSAgc3lz4oCQCiAgICAgICB0ZW0gb3IgZmlsZXN5 c3RlbSByZXNwZWN0aXZlbHkuCgpFeGNsdWRpbmcgdGhlIHJvb3QgY2dyb3VwLCBkbyB5b3UgdGhp bmsgYSBzeW5jKCkgaXNzdWVkIGluc2lkZSBhCnNwZWNpZmljIGNncm91cCBzaG91bGQgd2FpdCBm b3IgSS9PIGNvbXBsZXRpb25zIG9ubHkgZm9yIHRoZSB3cml0ZXMgdGhhdApoYXZlIGJlZW4gZ2Vu ZXJhdGVkIGJ5IHRoYXQgY2dyb3VwPwoKVGhhbmtzLAotQW5kcmVhCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91B9FC61CE4 for ; Sat, 19 Jan 2019 10:08:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4F3032086A for ; Sat, 19 Jan 2019 10:08:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="qmDXJpod" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727749AbfASKId (ORCPT ); Sat, 19 Jan 2019 05:08:33 -0500 Received: from mail-wr1-f66.google.com ([209.85.221.66]:46669 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727702AbfASKId (ORCPT ); Sat, 19 Jan 2019 05:08:33 -0500 Received: by mail-wr1-f66.google.com with SMTP id l9so17851032wrt.13; Sat, 19 Jan 2019 02:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=8F9NLQ6kP99EptHHFDvN202g5hUHgqJdJYyjeX/YXZo=; b=qmDXJpodc+pzhJoUOEw4j279PeQ4AAN50Gm2xzZNjxVx9iy2udr4/uKYydWi2hVZks OBWcy8NNrkpwVtv6HeIWleQGLeQUyjzWoul6X4uKQ3+CG3RSEkgaPFdIbFKLBmcVmmU4 kQs1EEbrrkimfrs38N9MdpMpxNVWg+8kxcSxE8ORpi2bQdBdZ2qHkhZRWsckGGYun2Dk 79jR8Btfk5I6HSF9lnIAUsLq8xSU7iK0W+K9FlqKAxwyYIMLmSHQQ8gCM1Znq5gTbCtL P7d8xjlPFkcFC6ex/+21RJaA1jQJ8egHLg3wxAGxWohSz6H9A7y5VPPerDuHGvcaaFSS J9ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=8F9NLQ6kP99EptHHFDvN202g5hUHgqJdJYyjeX/YXZo=; b=lvxifBBucMFVwo/fH+tHeePKwb278toesMu/iKjDiMkkZCgHjko57+NJqcboASyQBT ibJb/7Ch3M8rluIhlTHiGdDZEpwI8LoI9b8c7Ie7SBR1JDYG0zMqGy+RvRzKj9dldC8C Xo4q/7fDEW3zjC5sukwmE4o4ZruVsodA+iblER79hY9xLf1Hlx1NvjQ+C/U6Agtd9/FJ F57WxePrRoAMG2/O+SsCcC2H7sbBP9n/FvtR/YxKy2n9v1ms/tOEo9XdtYPq2PXzghI+ zy/9deuUDWNRYRMTPJVs1GgIXWW1aOptLR2SW5XRzK5WY8QRokyovhAB2KoC4ATJfjSI +JNA== X-Gm-Message-State: AJcUukegeseAFowub3r5kraqNgDo4f8UC9KnUCZgMMT1jh3iAwAaWfM/ tpYlnvbHMgtOFYfWCG9Gg0bbavue9Q== X-Google-Smtp-Source: ALg8bN47r3Km/D7Kul3h49yiZNWaF09WJTtdtmL7LTZNF37JzaELMeUWePRH+PEDJkGE02VadwhiIQ== X-Received: by 2002:adf:ba05:: with SMTP id o5mr19275065wrg.325.1547892510242; Sat, 19 Jan 2019 02:08:30 -0800 (PST) Received: from localhost (host150-62-dynamic.57-82-r.retail.telecomitalia.it. [82.57.62.150]) by smtp.gmail.com with ESMTPSA id h62sm34769616wmf.11.2019.01.19.02.08.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 19 Jan 2019 02:08:29 -0800 (PST) Date: Sat, 19 Jan 2019 11:08:27 +0100 From: Andrea Righi To: Josef Bacik Cc: Tejun Heo , Li Zefan , Johannes Weiner , Jens Axboe , Vivek Goyal , Dennis Zhou , cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/3] cgroup: fsio throttle controller Message-ID: <20190119100827.GA1630@xps-13> References: <20190118103127.325-1-righi.andrea@gmail.com> <20190118163530.w5wpzpjkcnkektsp@macbook-pro-91.dhcp.thefacebook.com> <20190118184403.GB1535@xps-13> <20190118194652.gg5j2yz3h2llecpj@macbook-pro-91.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190118194652.gg5j2yz3h2llecpj@macbook-pro-91.dhcp.thefacebook.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Fri, Jan 18, 2019 at 02:46:53PM -0500, Josef Bacik wrote: > On Fri, Jan 18, 2019 at 07:44:03PM +0100, Andrea Righi wrote: > > On Fri, Jan 18, 2019 at 11:35:31AM -0500, Josef Bacik wrote: > > > On Fri, Jan 18, 2019 at 11:31:24AM +0100, Andrea Righi wrote: > > > > This is a redesign of my old cgroup-io-throttle controller: > > > > https://lwn.net/Articles/330531/ > > > > > > > > I'm resuming this old patch to point out a problem that I think is still > > > > not solved completely. > > > > > > > > = Problem = > > > > > > > > The io.max controller works really well at limiting synchronous I/O > > > > (READs), but a lot of I/O requests are initiated outside the context of > > > > the process that is ultimately responsible for its creation (e.g., > > > > WRITEs). > > > > > > > > Throttling at the block layer in some cases is too late and we may end > > > > up slowing down processes that are not responsible for the I/O that > > > > is being processed at that level. > > > > > > How so? The writeback threads are per-cgroup and have the cgroup stuff set > > > properly. So if you dirty a bunch of pages, they are associated with your > > > cgroup, and then writeback happens and it's done in the writeback thread > > > associated with your cgroup and then that is throttled. Then you are throttled > > > at balance_dirty_pages() because the writeout is taking longer. > > > > Right, writeback is per-cgroup and slowing down writeback affects only > > that specific cgroup, but, there are cases where other processes from > > other cgroups may require to wait on that writeback to complete before > > doing I/O (for example an fsync() to a file shared among different > > cgroups). In this case we may end up blocking cgroups that shouldn't be > > blocked, that looks like a priority-inversion problem. This is the > > problem that I'm trying to address. > > Well this case is a misconfiguration, you shouldn't be sharing files between > cgroups. But even if you are, fsync() is synchronous, we should be getting the > context from the process itself and thus should have its own rules applied. > There's nothing we can do for outstanding IO, but that shouldn't be that much. > That would need to be dealt with on a per-contoller basis. OK, fair point. We shouldn't be sharing files between cgroups. I'm still not sure if we can have similar issues with metadata I/O (that may introduce latencies like the sync() scenario), I have to investigate more and do more tests. > > > > > > > > > I introduced the blk_cgroup_congested() stuff for paths that it's not easy to > > > clearly tie IO to the thing generating the IO, such as readahead and such. If > > > you are running into this case that may be something worth using. Course it > > > only works for io.latency now but there's no reason you can't add support to it > > > for io.max or whatever. > > > > IIUC blk_cgroup_congested() is used in readahead I/O (and swap with > > memcg), something like this: if the cgroup is already congested don't > > generate extra I/O due to readahead. Am I right? > > Yeah, but that's just how it's currently used, it can be used any which way we > feel like. I think it'd be very interesting to have the possibility to either throttle I/O before writeback or during writeback. Right now we can only throttle writeback. Maybe we can try to introduce some kind of dirty page throttling controller using blk_cgroup_congested()... Opinions? > > > > > > > > > > > > > > = Proposed solution = > > > > > > > > The main idea of this controller is to split I/O measurement and I/O > > > > throttling: I/O is measured at the block layer for READS, at page cache > > > > (dirty pages) for WRITEs, and processes are limited while they're > > > > generating I/O at the VFS level, based on the measured I/O. > > > > > > > > > > This is what blk_cgroup_congested() is meant to accomplish, I would suggest > > > looking into that route and simply changing the existing io controller you are > > > using to take advantage of that so it will actually throttle things. Then just > > > sprinkle it around the areas where we indirectly generate IO. Thanks, > > > > Absolutely, I can probably use blk_cgroup_congested() as a method to > > determine when a cgroup should be throttled (instead of doing my own > > I/O measuring), but to prevent the "slow writeback slowing down other > > cgroups" issue I still need to apply throttling when pages are dirtied > > in page cache. > > Again this is just a fuckup from a configuration stand point. The argument > could be made that sync() is probably broken here, but I think the right > solution here is to just pass the cgroup context along with the writeback > information and use that if it's set instead. Thanks, Alright, let's skip the root cgroup for now. I think the point here is if we want to provide sync() isolation among cgroups or not. According to the manpage: sync() causes all pending modifications to filesystem metadata and cached file data to be written to the underlying filesystems. And: According to the standard specification (e.g., POSIX.1-2001), sync() schedules the writes, but may return before the actual writing is done. However Linux waits for I/O completions, and thus sync() or syncfs() provide the same guarantees as fsync called on every file in the sys‐ tem or filesystem respectively. Excluding the root cgroup, do you think a sync() issued inside a specific cgroup should wait for I/O completions only for the writes that have been generated by that cgroup? Thanks, -Andrea