Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1200766imm; Wed, 18 Jul 2018 19:27:58 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfCQ71ZBTouV9sIVpVKfGCYnGqzVwMmtaonIF/kqsiaUWCrB4JVQ0HBicqLmVrAEtvPedTO X-Received: by 2002:a63:e145:: with SMTP id h5-v6mr7958694pgk.286.1531967278532; Wed, 18 Jul 2018 19:27:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531967278; cv=none; d=google.com; s=arc-20160816; b=NKbQtGjJt+0/o/bS2tiL1Uo2AxGTF9b6vcfuv78T2HU/U8vFPG97mvqqOCCjASOSAf RbxVTefoD7hImMk0+uN9hO44/meK9chKonSvf2no7W+17QSAUceRoirr9t2B9IvAQ8nz FDw4eYBYufaQiEPDRiVGGuIscdx3YrL21ijJQvZy0BgOhi90miHY48IEmIBy8McoY+wR bBsu3+3YhSGsSrUEhf5jXIro0gPttk1g+UtnEdtXFELpLJYfg0gv7klgwBIJl5qbObQ3 MODrrNVBd5FzIfkMPo947q/VZ74D22wnmYSAMx+qgN+NCYQqUGIGoIlsWmhs4KMyVVIo cD5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:arc-authentication-results; bh=w8ZdHcMcYnr6TPyKxEZvZiWvX1vciQHiTs0422iklQA=; b=nIpRogiVgRNUZ89cmz7qtZ9qnv77Z76V0VVynav9TQ6l2Uy8+UFvKux7iBTeHC9CRW IXsaUrSzlAd0G4/1ZtlQ1Fk8QqMmYZFm8MdVjWcSbDlJu2+wzIkjoPqQfM6rcf7nplOt 7yoYjaK/ZimG4YnDINHXVIezZY8ZuRMDDOamJ/UCN8Ro1YmvG+MG0Hq4MxsfGR4BpIJ/ EAMafFDwaj3Ed4ADNCboVnHvevFIT9epCOw1MQmv9Ie8XcMkftYWa/5S4xXWgxiSqxvY /hrQaFbCHJeRdQR4jIe79fgnPa0H6G5B5PztzRo0pfHOQPgm2exZhZGAJCvF4aHrQqZU DiAg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a4-v6si5375815pfk.253.2018.07.18.19.27.43; Wed, 18 Jul 2018 19:27:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731288AbeGSDHt (ORCPT + 99 others); Wed, 18 Jul 2018 23:07:49 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:9699 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730811AbeGSDHt (ORCPT ); Wed, 18 Jul 2018 23:07:49 -0400 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id B51BC2844B840; Thu, 19 Jul 2018 10:26:50 +0800 (CST) Received: from [10.177.253.249] (10.177.253.249) by smtp.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.382.0; Thu, 19 Jul 2018 10:26:52 +0800 Subject: Re: [PATCH] net/9p/trans_virtio.c: replace mutex_lock with spin_lock to protect 'virtio_chan_list' To: Dominique Martinet References: <5B4EF511.7090104@huawei.com> <20180718095420.GA28377@nautica> CC: "akpm@linux-foundation.org" , "Eric Van Hensbergen" , Ron Minnich , "Latchesar Ionkov" , Linux Kernel Mailing List , From: piaojun Message-ID: <5B4FF6DB.1040101@huawei.com> Date: Thu, 19 Jul 2018 10:26:35 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20180718095420.GA28377@nautica> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.253.249] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Dominique, On 2018/7/18 17:54, Dominique Martinet wrote: > piaojun wrote on Wed, Jul 18, 2018: >> spin_lock is more effective for short time protection than mutex_lock, as >> mutex lock may cause process sleep and wake up which consume much cpu >> time. > > That's not a fast path operation, I don't mind changing things but I'd > like to understand why - these functions are only ever called at unmount > time or when something happens on the virtio bus (probe will happen on > probing on the pci bus and I'm not too sure on remove but probably pci > removal i.e. basically never?) > > I don't see why this wouldn't work, but I won't take this without a > (good?) reason. > virtio_9p_lock is responsable for protecting virtio_chan_list which has 3 operation: 1. Add a virtio chan to virtio_chan_list. This will happen when we insmod 9pnet_virtio.ko: p9_virtio_probe --list_add_tail(&chan->chan_list, &virtio_chan_list); 2. Remove a virtio chan. This will happen when remnod 9pnet_virtio.ko: p9_virtio_remove --list_del(&chan->chan_list); 3. Find a unused virtio chan when mount 9p: mount --p9_virtio_create --list_for_each_entry(chan, &virtio_chan_list, chan_list) Multi mount process will compete for virtio_9p_lock when finding unused virtio chan, in which case mutex lock will cause process sleep and wake up. I think this a waste of CPU time. So we could use spin lock to avoid this. Thanks, Jun