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.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_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 319FEC433E1 for ; Tue, 26 May 2020 14:28:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EA01520870 for ; Tue, 26 May 2020 14:28:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TLMKcn3x" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EA01520870 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8293F800AC; Tue, 26 May 2020 10:28:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B21F80061; Tue, 26 May 2020 10:28:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67A40800AC; Tue, 26 May 2020 10:28:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0042.hostedemail.com [216.40.44.42]) by kanga.kvack.org (Postfix) with ESMTP id 4D1B380061 for ; Tue, 26 May 2020 10:28:09 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 0A99A180AD807 for ; Tue, 26 May 2020 14:28:09 +0000 (UTC) X-FDA: 76859099898.15.arm74_29fc1c06bfd44 X-HE-Tag: arm74_29fc1c06bfd44 X-Filterd-Recvd-Size: 5424 Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Tue, 26 May 2020 14:28:08 +0000 (UTC) Received: by mail-qk1-f193.google.com with SMTP id w3so15196826qkb.6 for ; Tue, 26 May 2020 07:28:08 -0700 (PDT) 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:in-reply-to; bh=0TJ6yYccZvVBdf4f/G2i6OowH5C25Z8m9Ap0zEnVgR8=; b=TLMKcn3xE73A18nE6utedMS8Vz8HXK+b0q/Divfxr42WLvfCj1VnejFo7V5BPdLF0q W+VJW80hsx5pkyn2afaGJzSd1NY9lzi/WflZh7Okd/ujLflmIzup/UUhAjVe3hjLW/ov /ckbc/JaidWP13F1n6QRu3E3MBXNO+SL6qBL9nAMf03UnJq5zUo+MGasn74WqYB3nHlM RMvAQzvfJ3xtHcnQf7mOLh7b54gRFUEIEGn2cQ5cWzw7drZMeoCaq8lvxlN5DiCjmw1j OWij/qP1w+bHGLFTVBEmayKa6pI5nJLWTt6wzU97k3DMGp051NXEEKMYkQDFm1nLdmm9 mfkA== 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:in-reply-to; bh=0TJ6yYccZvVBdf4f/G2i6OowH5C25Z8m9Ap0zEnVgR8=; b=IzEk1Yaxr2iZ3AkFOVhg6C5uv4Ja2d2o62YEzj3wTX2rQ+eIIsAjo2FSpbrk6MWu1u dg0Yz92a6+a3WHF5dl3ZcG7+KBNCZLGOnUPfioY5WjCnQilp47fwbpw8/8/Uw5JHtRyr Uhy3zf03nk1nRz7WpeDi/uIMpAnYwmnNRdzs7wy+nImk+h7KvtB+p4408xBQDsWhyC54 LqH7qHGb5bLf81FGFqiyYJzDp1lix+3aFKDivmwoHFzvleUlh8YAALRDJzCfuV4AzRSh anAyPKXFvKRtOT3BSOGmzTFEaz/wV7uT9DL+uUH9sc6yb0hMNHnyUITD0d8uMxKyTi9W xjmw== X-Gm-Message-State: AOAM530fx1hxsRfSvcU5zZYdRZ/fKIWQ+LQ46QxHTt5N0upi8+t4cUT/ Wa0zxOUynHwsgR2qE0pmAmw= X-Google-Smtp-Source: ABdhPJyK3oMuyeJ+F6B+ZijqpLzxAJ4vgdbS/Dm2ZGwMW4CXq3uWQNM1w7dewvLbX9tlS3HD2SWAuA== X-Received: by 2002:a37:78c1:: with SMTP id t184mr1585988qkc.213.1590503287516; Tue, 26 May 2020 07:28:07 -0700 (PDT) Received: from dschatzberg-fedora-PC0Y6AEN.dhcp.thefacebook.com ([2620:10d:c091:480::1:6991]) by smtp.gmail.com with ESMTPSA id i14sm4786794qkl.105.2020.05.26.07.28.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 May 2020 07:28:06 -0700 (PDT) Date: Tue, 26 May 2020 10:28:03 -0400 From: Dan Schatzberg To: Christoph Hellwig Cc: Jens Axboe , Alexander Viro , Jan Kara , Amir Goldstein , Tejun Heo , 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: <20200526142803.GA1061@dschatzberg-fedora-PC0Y6AEN.dhcp.thefacebook.com> References: <20200428161355.6377-1-schatzberg.dan@gmail.com> <20200512132521.GA28700@dschatzberg-fedora-PC0Y6AEN.dhcp.thefacebook.com> <20200512133545.GA26535@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200512133545.GA26535@infradead.org> 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: On Tue, May 12, 2020 at 06:35:45AM -0700, Christoph Hellwig wrote: > On Tue, May 12, 2020 at 09:25:21AM -0400, Dan Schatzberg wrote: > > Seems like discussion on this patch series 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 are addressed. > > > > Jens, you've expressed interest in seeing this series go through the > > block tree so I'm interested in your perspective here. Barring any > > concrete implementation bugs, would you be okay merging this version? > > Independ of any higher level issues you need to sort out the spinlock > mess I pointed out. Will do - I'll split out the lock-use refactor into a separate patch. Do you have particular concerns about re-using the existing spinlock? Its existing use is not contended so I didn't see any harm in extending its use. I'll add this justification to the commit message as well, but I'm tempted to leave the re-use as is instead of creating a new lock.