Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 19 Apr 2022 10:16:24 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Jens Axboe <axboe@kernel.dk>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Zhihao Cheng <chengzhihao1@huawei.com>,
        Ingo Molnar <mingo@redhat.com>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Christoph Hellwig <hch@lst.de>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        yukuai3@huawei.com
Subject: Re: [PATCH v2] fs-writeback: =?utf-8?Q?wri?=
 =?utf-8?Q?teback=5Fsb=5Finodes=EF=BC=9ARecalculat?= =?utf-8?Q?e?= 'wrote'
 according skipped pages
Message-ID: <20220419081624.GM2731@worktop.programming.kicks-ass.net>
References: <20220418092824.3018714-1-chengzhihao1@huawei.com>
 <CAHk-=wh7CqEu+34=jUsSaMcMHe4Uiz7JrgYjU+eE-SJ3MPS-Gg@mail.gmail.com>
 <587c1849-f81b-13d6-fb1a-f22588d8cc2d@kernel.dk>
 <CAHk-=wjmFw1EBOVAN8vffPDHKJH84zZOtwZrLpE=Tn2MD6kEgQ@mail.gmail.com>
 <df4853fb-0e10-4d50-75cd-ee9b06da5ab1@kernel.dk>
 <CAHk-=wg6s5gHCc-JngKFfOS7uZUrT9cqzNDKqUQZON6Txfa_rQ@mail.gmail.com>
 <69f80fe3-5bec-f02e-474b-e49651f5818f@kernel.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <69f80fe3-5bec-f02e-474b-e49651f5818f@kernel.dk>
Precedence: bulk

On Mon, Apr 18, 2022 at 06:30:16PM -0600, Jens Axboe wrote:
> On 4/18/22 6:19 PM, Linus Torvalds wrote:
> > On Mon, Apr 18, 2022 at 3:12 PM Jens Axboe <axboe@kernel.dk> wrote:
> >>
> >> Hmm yes. But doesn't preemption imply a full barrier? As long as we
> >> assign the plug at the end, we should be fine. And just now looking that
> >> up, there's even already a comment to that effect in blk_start_plug().
> >> So barring any weirdness with that, maybe that's the solution.
> > 
> > My worry is more about the code that adds new cb_list entries to the
> > plug, racing with then some random preemption event that flushes the
> > plug.
> > 
> > preemption itself is perfectly fine wrt any per-thread data updates
> > etc, but if preemption then also *changes* the data that is updated,
> > that's not great.
> > 
> > So that worries me.
> 
> Yes, and the same is true for eg merge traversal. We'd then need to
> disable preempt for that as well...

One is only supposed to disable preemption for short and bounded things,
otherwise we'll get people complaining their latencies are going bad.