Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932513Ab1C3OBo (ORCPT ); Wed, 30 Mar 2011 10:01:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54760 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754746Ab1C3OBn (ORCPT ); Wed, 30 Mar 2011 10:01:43 -0400 Date: Wed, 30 Mar 2011 10:01:24 -0400 From: Mike Snitzer To: Tejun Heo Cc: Jens Axboe , Vivek Goyal , Jeff Moyer , Markus Trippelsdorf , Sergey Senozhatsky , linux-kernel@vger.kernel.org, Chris Mason , hch@infradead.org Subject: Re: block: eliminate ELEVATOR_INSERT_REQUEUE Message-ID: <20110330140123.GA28212@redhat.com> References: <4D8CF202.9010809@kernel.dk> <20110326042156.GB28458@redhat.com> <20110328082321.GC16530@htj.dyndns.org> <20110328221547.GA1118@redhat.com> <20110329175458.GE24485@redhat.com> <20110330074123.GA17523@htj.dyndns.org> <20110330075752.GC17523@htj.dyndns.org> <4D92E2CD.6000909@kernel.dk> <20110330080203.GD17523@htj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110330080203.GD17523@htj.dyndns.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2008 Lines: 45 On Wed, Mar 30 2011 at 4:02am -0400, Tejun Heo wrote: > Hello, Jens. > > On Wed, Mar 30, 2011 at 09:59:09AM +0200, Jens Axboe wrote: > > Pure front insert should be used for requeue and internal commands (like > > spin up this drive, or get error information). Flush should append to > > the dispatch list. > > Yeah, right. The reason I used REQUEUE/FRONT was because BACK > insertion involves draining the elevator and then appending the > request at the end of the dispatch queue, which is unnecessary and > inefficient. So, front insertion was a quick work around that. If > we're removing elv_insert(), we can just append directly to the > dispatch queue from flush code. I'm trying to follow along but unrolling what was said above is challenging considering we're not getting rid of elv_insert()'s functionality; it was just folded into __elv_add_request() -- offering no functional change AFAIK. So placing special meaning on getting rid of elv_insert() is confusing me. Why can we all of a sudden append the flush to the dispatch queue _but_ not have any concern about queue draining? Seems that avoiding use of BACK, by using list_add_tail, is enabling that. Couldn't we have always done that? The folding of elv_insert() into __elv_add_request() seems irrelevant. Can we take a step back and be more explicit about the implications of having inserted the flush with REQUEUE/FRONT? Seems to me that having _not_ inserted the flush at the end of the dispatch queue is cause for potential corruption (preceding data hasn't been issued to the device yet). And just to be clear: none of this is a concern for stable right? It is just the flush-merge code introduced for 2.6.39 that needs fixing? Please advise, thanks! Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/