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 C47ADC83000 for ; Wed, 29 Apr 2020 14:22:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7D170206F0 for ; Wed, 29 Apr 2020 14:22:35 +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="PeLTcvnm" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D170206F0 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 2D41C8E0008; Wed, 29 Apr 2020 10:22:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 283CC8E0005; Wed, 29 Apr 2020 10:22:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 19AC78E0008; Wed, 29 Apr 2020 10:22:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0057.hostedemail.com [216.40.44.57]) by kanga.kvack.org (Postfix) with ESMTP id 026048E0005 for ; Wed, 29 Apr 2020 10:22:34 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B61B72481 for ; Wed, 29 Apr 2020 14:22:34 +0000 (UTC) X-FDA: 76761108228.25.card82_167259437895a X-HE-Tag: card82_167259437895a X-Filterd-Recvd-Size: 6352 Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Wed, 29 Apr 2020 14:22:34 +0000 (UTC) Received: by mail-qt1-f194.google.com with SMTP id k12so1958260qtm.4 for ; Wed, 29 Apr 2020 07:22:33 -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=U7CYd6LIahwn6A9pI4DbAiS85+k2nqU8qqxir3NJPME=; b=PeLTcvnmSUGReSfTmkROy81aqLORMcNPoEzmktkHawEeaPG9HbIpOgkxRx5xsqTpQN 9WOnAOZe+xH0FileYYcNrelmGXfu6azM0W+0j00Gqz4DY4IH06QvwINlT5pc+HSxL/pK tL9rAA6decLe+wa6vxDWO8g3zqtmubZwuiwPEoUptoWJA3+7KoA+MkgAtnVVhQJUM9DY wpTIQHbFB4U9kPA+rHftrWb7uGODB+OAnl59MfqEMDVGQdAPHEeoDvi1SxtdIuuy/avM iKMnjfgO8zhSUvKYO2UoRaNkEWLAgHOzWvKrcLOGJ2S3I72q5M8zGXeI3EwZ/vf7SFyv ke6A== 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=U7CYd6LIahwn6A9pI4DbAiS85+k2nqU8qqxir3NJPME=; b=F8GKw2YEuSQh/c7NV9afSAe0b9NLsWdQcnrEAofczhGnEU9nKv8a4KRjyghAT2SkWS Juvks5Zo3JShSik3v6UD3jXNC5DZCkBKq14bI7x7kDV8KH63JLVDj+XhpPKUaVXky38g NBRR9bTVOsckpOme+LhjQyyrzOUDK1TjWj+/rui+g0jEGqi7Uk+CByrFnMmFey1g9kI4 sEOEgyG+7yMwk5cTFjU5PfM4iM7drwY2ngH3ycnSG4T6mJAy33tZvve+aW/ZsC2mYrVr wIxTsyVxx7miHcpaV8LFPxLCgk2aY78F81QzKDzFgWS9VKV1LVtc+lkWA6nkySczwK0S NbqQ== X-Gm-Message-State: AGi0PuZ3Qeh/rAGmVo37GpyM1O4ubnchnsCoBt2Nic4Nql1W2tCVmw7H Myk6p3yMDFKb9/OP9e8ejH8= X-Google-Smtp-Source: APiQypJMW/FRQ0KNbQV06MDhEGIzJ6AnlD4J81Wkyk6TKWOsnJQLVg0yLyYny/w1ZGbIKtk1MV4xIA== X-Received: by 2002:aed:3ac8:: with SMTP id o66mr34282726qte.110.1588170153191; Wed, 29 Apr 2020 07:22:33 -0700 (PDT) Received: from localhost ([199.96.181.106]) by smtp.gmail.com with ESMTPSA id n13sm16521816qtf.15.2020.04.29.07.22.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Apr 2020 07:22:32 -0700 (PDT) Date: Wed, 29 Apr 2020 10:22:30 -0400 From: Tejun Heo To: Jan Kara Cc: Dave Chinner , 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: <20200429142230.GE5462@mtj.thefacebook.com> References: <20200428161355.6377-1-schatzberg.dan@gmail.com> <20200428214653.GD2005@dread.disaster.area> <20200429102540.GA12716@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200429102540.GA12716@quack2.suse.cz> 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, On Wed, Apr 29, 2020 at 12:25:40PM +0200, Jan Kara wrote: > Yeah, I was thinking about the same when reading the patch series > description. We already have some cgroup workarounds for btrfs kthreads if > I remember correctly, we have cgroup handling for flush workers, now we are > adding cgroup handling for loopback device workers, and soon I'd expect > someone comes with a need for DM/MD worker processes and IMHO it's getting > out of hands because the complexity spreads through the kernel with every > subsystem comming with slightly different solution to the problem and also > the number of kthreads gets multiplied by the number of cgroups. So I > agree some generic solution how to approach IO throttling of kthreads / > workers would be desirable. > > OTOH I don't have a great idea how the generic infrastructure should look > like... I don't really see a way around that. The only generic solution would be letting all IOs through as root and handle everything through backcharging, which we already can do as backcharging is already in use to handle metadata updates which can't be controlled directly. However, doing that for all IOs would make the control quality a lot worse as all control would be based on first incurring deficit and then try to punish the issuer after the fact. The infrastructure work done to make IO control work for btrfs is generic and the changes needed on btrfs side was pretty small. Most of the work was identifying non-regular IO pathways (bouncing through different kthreads and whatnot) and making sure they're annotating IO ownership and the needed mechanism correctly. The biggest challenge probably is ensuring that the filesystem doesn't add ordering dependency between separate data IOs, which is a nice property to have with or without cgroup support. That leaves the nesting drivers, loop and md/dm. Given that they sit in the middle of IO stack and proxy a lot of its roles, they'll have to be updated to be transparent in terms of cgroup ownership if IO control is gonna work through them. Maybe we can have a common infra shared between loop, dm and md but they aren't many and may also be sufficiently different. idk Thanks. -- tejun