Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp454120pxb; Wed, 27 Jan 2021 11:50:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJzh1NcZxos/jp4sBBfIxaWrHtrR/QzPlYundSvKjvqxJ8A5EsqrEtc8sKLG67znMQrGy3Ei X-Received: by 2002:a05:6402:2288:: with SMTP id cw8mr10357528edb.161.1611777027424; Wed, 27 Jan 2021 11:50:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611777027; cv=none; d=google.com; s=arc-20160816; b=t9mt6fHpfMb3Dc5KALfS9/UR2OcETpo9h2xzTj3OKyhtAmFeK5/s8+jEzDJd2hSQSR 83JDKQ9F0ukIJBqdHqukNctrA0uvnOXEoNpfjLX6Kg0AafnuvOcekqnCvdXtzV8GGerY ItruyU+dTVFcoWGKr9AnD2PNfNp0ICHRjWTkCztjyVqqVI3AGVQsSxBbosSrlCyemYuq L1NK8PaOJiS48eMJoSTiz2I0Ql4oRLsc2uqgKpeHRMd/WAGHGULxq85VO35cogPIIeCo HG+ovMEisw5vZ/6dEgpJkbSmE/jR1jAQWyA9hqD8ycm6ZRlbSp6XxYMZskachngkNVnI CfRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :to:subject:dkim-signature; bh=RFzsjs73B5QGolUY36etsSHceLP09/8jna6hDkWinoI=; b=Bf1lM5sTefYDFrY54dj9XiheSxyDHTQbB43bZcVb+KWE5DBZ3TcRrFRMw2YdygSuRW 459LONNpNF5DuzCLnadOmIcdiPJdjhE2b1Aiax2+FkzFVi0pvispPwccLnzzRDRy27NO EfqsyxkL68k5KjgOeaROj10ZFgRUXZF/ltfLQF/CvYkmV/KxDjZHw1oI953gTs3b//qi DD+HuW/6I3tENPKaBDPDsGOW4T/99VpXp867opI3PrcGs7a9J7krPdGXT2k8kyiQEAsP xNiiyOvyZ1lE79biZ5JLJjgIw4y5rIAD2pv/JQeXB3jfHokNlhGUApYieiitLbodWwNj 9SKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=NHT3FZZp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q12si1544665edn.552.2021.01.27.11.49.54; Wed, 27 Jan 2021 11:50:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=NHT3FZZp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235154AbhA0DPu (ORCPT + 99 others); Tue, 26 Jan 2021 22:15:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34340 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405293AbhAZUJt (ORCPT ); Tue, 26 Jan 2021 15:09:49 -0500 Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F20E1C061574 for ; Tue, 26 Jan 2021 12:09:08 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id i7so12166134pgc.8 for ; Tue, 26 Jan 2021 12:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=RFzsjs73B5QGolUY36etsSHceLP09/8jna6hDkWinoI=; b=NHT3FZZp9joO/4A2cIe+S9vs9lbh0VEwMmGIlFcM997cgIKdCTtbDRMw4vIA8MMDdf 6jcCKXxlNPkYB8uu8Hy+MaYzrcgk3VKsx2mI9hjgdhZe72QkNP4jUkynGfyhyI0ITftK 227BFngVq9IP8Wgi0ugTfmuPU4FVdvPhokdvsmjWzu+T+fPoJBlhy3Q4n2tsleUiNta0 6Py2C+w367MVGvQRkucb6NNdksabAslf+2p+oOiyJiF/FNPG7ExQ4vVuqt63u+NqL3H4 XatCkFDYUoDc2dcuDuNyVZTYgSwbubVLj78PUT9GqcK99Vh7sUSCVekPcyShTy7JHGpC F+Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RFzsjs73B5QGolUY36etsSHceLP09/8jna6hDkWinoI=; b=V07rocvBSvGBAGZeC3GwtMNeRDM0PEpJln9ANlep9QmFKgu56Y/DeVpZw+FKS2Xxqh /g+pqpSSazzH3NttHcmiC9j0jTGsbVMobfm0uTj/B9WVi9ThYQVyzzOuJNCetX97ws/T mIknPArUkuLH5L7+umlthSZ8xiAgEC6aSUFdurCg4Ev7ql2kMM9LP6RIbuW12V3B5OzE ZdxDX8ar2a0SBjY9r9g8gYDS2PMdzefewKPCbiyzkopu2rgCkGD7575hSChXqym70qPa 2imOpYY1v2ptzte0jLh3f2eiHjgpi8PM4uB/9H8VrH1W3omjp0i1kUVGWySUdPu2gv2e /aww== X-Gm-Message-State: AOAM530HW9TZGXAkCV2jSXyaUtroDqmsOMCuWu+GqH3Bm8xsyU0VrUgK apAbPxgD3CyZj1M7OoOTKzK29g== X-Received: by 2002:a62:380a:0:b029:1a9:5aa1:6d0d with SMTP id f10-20020a62380a0000b02901a95aa16d0dmr6617617pfa.45.1611691748448; Tue, 26 Jan 2021 12:09:08 -0800 (PST) Received: from [192.168.4.41] (cpe-72-132-29-68.dc.res.rr.com. [72.132.29.68]) by smtp.gmail.com with ESMTPSA id u126sm18970542pfu.113.2021.01.26.12.09.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Jan 2021 12:09:07 -0800 (PST) Subject: Re: [PATCH v4 1/1] loop: scale loop device by introducing per device lock To: Pavel Tatashin , tyhicks@linux.microsoft.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, sashal@kernel.org, jmorris@namei.org, lukas.bulwahn@gmail.com, hch@lst.de, pvorel@suse.cz, ming.lei@redhat.com, mzxreary@0pointer.de, mcgrof@kernel.org, zhengbin13@huawei.com, maco@android.com, colin.king@canonical.com, evgreen@chromium.org References: <20210126144630.230714-1-pasha.tatashin@soleen.com> <20210126144630.230714-2-pasha.tatashin@soleen.com> From: Jens Axboe Message-ID: Date: Tue, 26 Jan 2021 13:09:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210126144630.230714-2-pasha.tatashin@soleen.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/26/21 7:46 AM, Pavel Tatashin wrote: > Currently, loop device has only one global lock: loop_ctl_mutex. > > This becomes hot in scenarios where many loop devices are used. > > Scale it by introducing per-device lock: lo_mutex that protects > modifications of all fields in struct loop_device. > > Keep loop_ctl_mutex to protect global data: loop_index_idr, loop_lookup, > loop_add. > > The new lock ordering requirement is that loop_ctl_mutex must be taken > before lo_mutex. Applied, thanks. -- Jens Axboe