Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761119AbZAPAgb (ORCPT ); Thu, 15 Jan 2009 19:36:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753011AbZAPAgV (ORCPT ); Thu, 15 Jan 2009 19:36:21 -0500 Received: from accolon.hansenpartnership.com ([76.243.235.52]:35842 "EHLO accolon.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752228AbZAPAgU (ORCPT ); Thu, 15 Jan 2009 19:36:20 -0500 Subject: Re: [PATCH] block: export SSD/non-rotational queue flag through sysfs From: James Bottomley To: Hugh Dickins Cc: Grant Grundler , Jens Axboe , Greg Freemyer , Tejun Heo , Michael Tokarev , Kay Sievers , Bartlomiej Zolnierkiewicz , linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org, Alan Cox In-Reply-To: References: <200901051952.58029.bzolnier@gmail.com> <20090106073515.GY32491@kernel.dk> <4964866D.8010503@msgid.tls.msk.ru> <1231342473.3282.19.camel@localhost.localdomain> <496ECBA0.60209@gmail.com> <87f94c370901150707h10506e99reaa40c23e32ab18c@mail.gmail.com> <1232035561.5966.48.camel@localhost.localdomain> <1232046039.5966.54.camel@localhost.localdomain> <1232061429.5966.87.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 15 Jan 2009 19:36:14 -0500 Message-Id: <1232066174.5966.92.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1779 Lines: 37 On Thu, 2009-01-15 at 23:50 +0000, Hugh Dickins wrote: > On Thu, 15 Jan 2009, James Bottomley wrote: > > > > OK, so they could be calculated on the fly in the elevators, I suppose. > > But what would the value be? Right now we use the nonrotational flag to > > basically not bother with plugging (no point if no seek penalty) on > > certain events where we'd previously have waited for other I/O to join. > > But that's really a seek penalty parameter rather than the idea of read > > or write costing (although the elevators usually track these dynamically > > anyway ... as part of the latency calculations but not explicitly). > > ... not bother with plugging (no point if no seek penalty) ... > > I thought there was considerable advantage to plugging writes > (in case they turn out to be adjacent) on current and older > generations of non-rotational storage? Heh, you get as many answers to that one as their are SSD manufacturers. However, the consensus seems to be that all MLC and SLC flash has a RAID like architecture internally, thus it can actually be *faster* if you send multiple commands (each area of the RAID processes independently). Of course, you have to be *able* to send multiple commands, so the device must implement TCQ/NCQ, but if it does, it's actually beneficial *not* to wait even if the requests are adjacent. However, the reason the nonrotational flag is set from user space is precisely so if we do find an SSD that has this property, we can just not set the nonrotational queue flag. James -- 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/