From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.9]:57681 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751168AbcFIQAs (ORCPT ); Thu, 9 Jun 2016 12:00:48 -0400 Date: Thu, 9 Jun 2016 09:00:46 -0700 From: Christoph Hellwig To: Jeff Moyer Cc: Jens Axboe , linux-block@vger.kernel.org, Christoph Hellwig Subject: Re: [PATCH] cfq: priority boost on meta/prio marked IO Message-ID: <20160609160046.GA30239@infradead.org> References: <20160608204347.GA30146@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-block-owner@vger.kernel.org List-Id: linux-block@vger.kernel.org On Thu, Jun 09, 2016 at 11:55:56AM -0400, Jeff Moyer wrote: > I expect a higher prio process could be blocked on a lower prio process > reading the same metadata, too. I had a hard time tracking down where > REQ_META WRITE I/O was issued outside of the journal or writeback paths > (and I hope you're not ionice-ing those!). Eventually, with the help of > sandeen, I found some oddball cases that I doubt you're running into. > Can you enlighten me as to where this (REQ_META write I/O) is happening? > I don't disagree that it's a problem, I just would like to understand > your problem case better. XFS does lots of REQ_META writes from _xfs_buf_ioapply(). But none of those should be in the critical path as the all metadata is logged first and then written back later. > Anyway, it seems to me you could just set REQ_PRIO in the code paths you > care about instead of modifying CFQ to treat REQ_META and REQ_PRIO as > the same thing, which essentially undoes commit 65299a3b788bd ("block: > separate priority boosting from REQ_META") from Christoph. And I'm still waiting for someone to explain when exactly REQ_PRIO should be used..