From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail-oi0-f68.google.com ([209.85.218.68]:41595 "EHLO
        mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1732215AbeHGOg5 (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Tue, 7 Aug 2018 10:36:57 -0400
Received: by mail-oi0-f68.google.com with SMTP id k12-v6so27991882oiw.8
        for <linux-fsdevel@vger.kernel.org>; Tue, 07 Aug 2018 05:22:52 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <153303273523.387.7541221195413649436.stgit@localhost.localdomain>
References: <153303268481.387.10809229593975235816.stgit@localhost.localdomain>
 <153303273523.387.7541221195413649436.stgit@localhost.localdomain>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Tue, 7 Aug 2018 14:22:51 +0200
Message-ID: <CAJfpeguKJ2mAJbZjg+RVrzsGGJz-6WJ5Oa821Pw+udcc8E5HnA@mail.gmail.com>
Subject: Re: [PATCH 2/2] fuse: Move clear_bit() up in request_end()
To: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: linux-fsdevel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Tue, Jul 31, 2018 at 12:25 PM, Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
> Nobody can clear FR_BACKGROUND bit on processing
> request in parallel, so it's possible to do it
> out of fc->lock.

Moving such a cheap operation outside the splinlock won't make any
difference in real life.

And anyway the biggest problem with fc->lock is not contention (hold
for long period of time), I would guess, but cachline pingponging
(being acquired on different CPUs one after the other).

So there's definitely work to do regarding locking in fuse, but it
needs a bigger axe.

Thanks,
Miklos