From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roman Gushchin Subject: Re: [PATCH v6 0/4] Charge loop device i/o to issuing cgroup Date: Fri, 21 Aug 2020 13:05:30 -0700 Message-ID: <20200821200530.GA2250889@carbon.dhcp.thefacebook.com> References: <20200528135444.11508-1-schatzberg.dan@gmail.com> <20200821150405.GA4137@dschatzberg-fedora-PC0Y6AEN.dhcp.thefacebook.com> <20200821160128.GA2233370@carbon.dhcp.thefacebook.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=date : from : to : cc : subject : message-id : references : content-type : in-reply-to : mime-version; s=facebook; bh=wUAx8CXyWwn0REf5nzJmEo+bX91x9dOeaJe1nMET1Gg=; b=Oslhq6o2PIblXvTVmHCjo4SijNPQVmGfKdYoqXQqBHO13WQT047ih0ITfb6U5BueC2mZ h9PQnAIRQ4fwj7immsjbjDhvtIorA6GXB01yIWZFYgj80U/8HBMI2D+YCx0K1TfQ0DHW Vu4ExOSLjMgiHUrbh4kIFRF0IrM11zFI3yI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector2-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wUAx8CXyWwn0REf5nzJmEo+bX91x9dOeaJe1nMET1Gg=; b=jp+E+qei1X3icW308uDTJBMcElt7uyh9dQLaB+hbilKeoxNe+iTjXjHaq3IfCQsLeXMFdEvGxziRc8iQtdeoWf+Bk9KyTS1msqvEZewf7/rE9L9cphBdYYbCEQGU8UIRZQ1WZJEZXegOUfh1Lkh+p6TudUsQ4RzaWd1qMHzMtCU= Content-Disposition: inline In-Reply-To: Sender: linux-block-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Shakeel Butt Cc: Dan Schatzberg , Jens Axboe , Alexander Viro , Jan Kara , Amir Goldstein , Tejun Heo , Li Zefan , Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Hugh Dickins , Chris Down , Yang Shi , Thomas Gleixner , "Peter Zijlstra (Intel)" , Ingo Molnar , Mathieu Desnoyers , Andrea Arcangeli , "open list:BLOCK LAYER" On Fri, Aug 21, 2020 at 09:27:56AM -0700, Shakeel Butt wrote: > On Fri, Aug 21, 2020 at 9:02 AM Roman Gushchin wrote: > > > > On Fri, Aug 21, 2020 at 11:04:05AM -0400, Dan Schatzberg wrote: > > > On Thu, Aug 20, 2020 at 10:06:44AM -0700, Shakeel Butt wrote: > > > > On Thu, May 28, 2020 at 6:55 AM Dan Schatzberg wrote: > > > > > > > > > > Much of the discussion about this has died down. There's been a > > > > > concern raised that we could generalize infrastructure across loop, > > > > > md, etc. This may be possible, in the future, but it isn't clear to me > > > > > how this would look like. I'm inclined to fix the existing issue with > > > > > loop devices now (this is a problem we hit at FB) and address > > > > > consolidation with other cases if and when those need to be addressed. > > > > > > > > > > > > > What's the status of this series? > > > > > > Thanks for reminding me about this. I haven't got any further > > > feedback. I'll bug Jens to take a look and see if he has any concerns > > > and if not send a rebased version. > > > > Just as a note, I stole a patch from this series called > > "mm: support nesting memalloc_use_memcg()" to use for the bpf memory accounting. > > I rewrote the commit log and rebased to the tot with some trivial changes. > > > > I just sent it upstream: > > https://lore.kernel.org/bpf/20200821150134.2581465-1-guro@fb.com/T/#md7edb6b5b940cee1c4d15e3cef17aa8b07328c2e > > > > It looks like we need it for two independent sub-systems, so I wonder > > if we want to route it first through the mm tree as a standalone patch? > > > > Another way is to push that patch to 5.9-rc2 linus tree, so both block > and mm branches for 5.10 will have it. (Not sure if that's ok.) Ok, it looks like the patch provides a generally useful API enhancement. And we do have at least two potential use cases for it. Let me send it as a standalone patch to linux-mm@. Btw, Shakeel, what do you think of s/memalloc_use_memcg()/set_active_memcg() ? And thank you for reviews! Roman