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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 F2EC4C47257 for ; Tue, 5 May 2020 15:38:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A3B5E206B9 for ; Tue, 5 May 2020 15:38:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Qgxse7dV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A3B5E206B9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2512B8E0007; Tue, 5 May 2020 11:38:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 200288E0003; Tue, 5 May 2020 11:38:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0EF468E0007; Tue, 5 May 2020 11:38:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0156.hostedemail.com [216.40.44.156]) by kanga.kvack.org (Postfix) with ESMTP id EC3438E0003 for ; Tue, 5 May 2020 11:38:39 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B1C3C180AD811 for ; Tue, 5 May 2020 15:38:39 +0000 (UTC) X-FDA: 76783072758.21.verse51_1156d16a0994c X-HE-Tag: verse51_1156d16a0994c X-Filterd-Recvd-Size: 7166 Received: from mail-qv1-f65.google.com (mail-qv1-f65.google.com [209.85.219.65]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Tue, 5 May 2020 15:38:38 +0000 (UTC) Received: by mail-qv1-f65.google.com with SMTP id v10so1212922qvr.2 for ; Tue, 05 May 2020 08:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=BXdArichtJxJSpMdJATI60C/n/3lvsy1fL/KOG1aR0o=; b=Qgxse7dVakSkufrx/Jt+udb+ymexH65VUMnEUWLtLKEfqRpwkmZlz5vI4O25vYATuy VVaC5aOnEDpNMe0z4vb1MBK8RuTdKfE1z+9MXMsUa8Z7ppPI9jeLSH+Y8Hs6hSeLIt7Z XdQeFLLxaDYlVJjnLRQT2fRAPqAx2+GxrlAFS5lYDNwWv5TZOo8aje30hyhqww7q5VgE hFxkjqHOBiRON9nOAlxbQxTz+54tsN16QGn69GNDWSv9wEK3DmoNTZSaJqVrx9A7Mk8y 00VmVkyFxFDtx76koAUjHf4CeJ1KqeHm5lGGRIjrmR90TSFZ8z6JZKNkLs+fowxAlB76 0AAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=BXdArichtJxJSpMdJATI60C/n/3lvsy1fL/KOG1aR0o=; b=ir43cHg1nKAXrkmuTn3DgYFKUzKNqaHUerlPVdrDTu7qBLxjU/cTdmBFxiyUxg5K8U tpceYN0jCxeQoL+sNL4WbWMdNmS2UxFeyNSS43G3ml6PTXRk1M46gzqBeOXH8uksQ5K9 ySDEex/rkfFd6YL8gUMwltn5yL5lhNNQgT+bLYot7JBf4oJE3m4P4xcN1+vdpo63Qdm5 1OdXfdwdGfGcRW9M4CrCe6F50BchTEKlFAYzbJ5wgeNqStDOOzO498Chwum+ZiKzQLAJ VbfFODuvQnP9xCdiLYkhTkZ8MHfQcPhwS/MY/f4QCX3e5y6fNkInbBWqMzAn/SUtMgVz vkgw== X-Gm-Message-State: AGi0PubuPxxFfq2TCAkd3aCE1Io1dMSenS0z0YNh8wPri1uqvLxuoFnE kXVtHgshqIcxLu+3ndvb60o= X-Google-Smtp-Source: APiQypIPmFzcysooPjiBb3SJnZHAzyV6pGruCekUBQbAVqyGjNBnCjfYXl4LmSQBc0QeZ7N4HNPQQA== X-Received: by 2002:ad4:434a:: with SMTP id q10mr3378243qvs.81.1588693118118; Tue, 05 May 2020 08:38:38 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:5ece]) by smtp.gmail.com with ESMTPSA id q62sm2071319qke.22.2020.05.05.08.38.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2020 08:38:37 -0700 (PDT) Date: Tue, 5 May 2020 11:38:34 -0400 From: Tejun Heo To: Dave Chinner Cc: Jan Kara , Dan Schatzberg , Jens Axboe , Alexander Viro , Amir Goldstein , Li Zefan , Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Hugh Dickins , Roman Gushchin , Shakeel Butt , Chris Down , Yang Shi , Ingo Molnar , "Peter Zijlstra (Intel)" , Mathieu Desnoyers , "Kirill A. Shutemov" , Andrea Arcangeli , Thomas Gleixner , "open list:BLOCK LAYER" , open list , "open list:FILESYSTEMS (VFS and infrastructure)" , "open list:CONTROL GROUP (CGROUP)" , "open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)" Subject: Re: [PATCH v5 0/4] Charge loop device i/o to issuing cgroup Message-ID: <20200505153834.GA12217@mtj.thefacebook.com> References: <20200428161355.6377-1-schatzberg.dan@gmail.com> <20200428214653.GD2005@dread.disaster.area> <20200429102540.GA12716@quack2.suse.cz> <20200505064114.GI2005@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200505064114.GI2005@dread.disaster.area> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello, Dave. On Tue, May 05, 2020 at 04:41:14PM +1000, Dave Chinner wrote: > > OTOH I don't have a great idea how the generic infrastructure should look > > like... > > I haven't given it any thought - it's not something I have any > bandwidth to spend time on. I'll happily review a unified > generic cgroup-aware kthread-based IO dispatch mechanism, but I > don't have the time to design and implement that myself.... > > OTOH, I will make time to stop people screwing up filesystems and > block devices with questionable complexity and unique, storage > device dependent userspace visible error behaviour. This sort of > change is objectively worse for users than not supporting the > functionality in the first place. That probably is too strong a position to hold without spending at least some thoughts on a subject, whatever the subject may be, and it doesn't seem like your understanding of userspace implications is accurate. I don't necessarily disagree that it'd be nice to have a common infrastructure and there may be some part which can actually be factored out. However, there isn't gonna be a magic bullet which magically makes every IO thing in the kernel cgroup aware automatically. Please consider the followings. * Avoding IO priority inversions requires splitting IO channels according to cgroups and working around (e.g. with backcharging) when they can't be. It's a substantial feature which may require substantial changes. Each IO subsystem has different constraints and existing structures and many of them would require their own solutions. It's not different from different filesystems needing their own solutions for similar problems. * Because different filesystems and IO stacking layers already have their own internal infrastructure, the right way to add cgroup support is adapting to and modifying the existing infrastructure rather than trying to restructure them to use the same cgroup mechanism, which I don't think would be possible in many cases. * Among the three IO stacking / redirecting mechanisms - md/dm, loop and fuse - the requirements and what's possible vary quite a bit. md/dm definitely need to support full-on IO channel splitting cgroup support. loop can go either way, but given existing uses, full splitting makes a sense. fuse, as it currently stands, can't support that because the priority inversions extend all the way to userspace and the kernel API isn't built for that. If it wants to support cgroup containment, each instance would have to be assigned to a cgroup. Between dm/md and loop, it's maybe possible that some of the sub-threading code can be reused, but I don't see a point in blocking loop updates given that it clearly fixes userspace visible malfunctions, is not that much code and how the shared code should look is unclear yet. We'll be able to answer the sharing question when we actually get to dm/md conversion. Thanks. -- tejun