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;
Date:   Wed, 18 Jul 2018 11:54:20 +0200
From:   Dominique Martinet <asmadeus@codewreck.org>
To:     piaojun <piaojun@huawei.com>
Cc:     "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        Eric Van Hensbergen <ericvh@gmail.com>,
        Ron Minnich <rminnich@sandia.gov>,
        Latchesar Ionkov <lucho@ionkov.net>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        v9fs-developer@lists.sourceforge.net
Subject: Re: [PATCH] net/9p/trans_virtio.c: replace mutex_lock with spin_lock
 to protect 'virtio_chan_list'
Message-ID: <20180718095420.GA28377@nautica>
References: <5B4EF511.7090104@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <5B4EF511.7090104@huawei.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.

-- 
Dominique Martinet