From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug()
Date: Mon, 28 Sep 2015 16:47:57 +0200
Message-ID: <20150928144757.GB2881@worktop.programming.kicks-ass.net>
References: <20150917235647.GG8624@ret.masoncoding.com>
 <20150918003735.GR3902@dastard>
 <CA+55aFzXW7t+1v3tmW2sxn-BLpvZ1_Ye6epiPWBeq70FoaSmFQ@mail.gmail.com>
 <20150918054044.GT3902@dastard>
 <CA+55aFw3Y51ZtaPK=r1dp66hDsGmc-dFz9wf-gYMGi5B0FP4KQ@mail.gmail.com>
 <20150918131615.GI8624@ret.masoncoding.com>
 <55FC1E72.3040500@fb.com>
 <CA+55aFznZFMHzGZr1ybY9wu_FuRJ-ZiJipuHM3brvHO7GybUpQ@mail.gmail.com>
 <20150918155956.GZ3816@twins.programming.kicks-ass.net>
 <CA+55aFyUPuAHrwHewH7356y=tAw=M+o_d0J5CqjjaDMzxN2AEA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Jens Axboe <axboe@fb.com>, Ingo Molnar <mingo@kernel.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Chris Mason <clm@fb.com>, Dave Chinner <david@fromorbit.com>,
	Jan Kara <jack@suse.cz>, Josef Bacik <jbacik@fb.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Neil Brown <neilb@suse.de>, Christoph Hellwig <hch@lst.de>,
	Tejun Heo <tj@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <CA+55aFyUPuAHrwHewH7356y=tAw=M+o_d0J5CqjjaDMzxN2AEA@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Fri, Sep 18, 2015 at 09:12:38AM -0700, Linus Torvalds wrote:
> 
> So I disagree with your notion that it's a recursion flag. It is
> absolutely nothing of the sort.

OK, agreed. I had it classed under recursion in my head, clearly I
indexed it sloppily. In any case I have a patch that kills off
PREEMPT_ACTIVE entirely.

I just have to clean it up, benchmark, split and write changelogs. But
it should be forthcoming 'soon'. As is, it boots..

> It gets set by preemption - and,
> somewhat illogically, by cond_resched().

I suspect that was done to make cond_resched() (voluntary preemption)
more robust and only have a single preemption path/logic. But all that
was done well before I got involved.