From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754277AbZHPOLr (ORCPT ); Sun, 16 Aug 2009 10:11:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752910AbZHPOLr (ORCPT ); Sun, 16 Aug 2009 10:11:47 -0400 Received: from earthlight.etchedpixels.co.uk ([81.2.110.250]:38828 "EHLO www.etchedpixels.co.uk" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751453AbZHPOLp (ORCPT ); Sun, 16 Aug 2009 10:11:45 -0400 Date: Sun, 16 Aug 2009 15:05:30 +0100 From: Alan Cox To: James Bottomley Cc: Mark Lord , Chris Worley , Matthew Wilcox , Bryan Donlan , david@lang.hm, Greg Freemyer , Markus Trippelsdorf , Matthew Wilcox , Hugh Dickins , Nitin Gupta , Ingo Molnar , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org, Linux RAID Subject: Re: Discard support (was Re: [PATCH] swap: send callback when swap slot is freed) Message-ID: <20090816150530.2bae6d1f@lxorguk.ukuu.org.uk> In-Reply-To: <1250344518.4159.4.camel@mulgrave.site> References: <200908122007.43522.ngupta@vflare.org> <20090813151312.GA13559@linux.intel.com> <20090813162621.GB1915@phenom2.trippelsdorf.de> <87f94c370908131115r680a7523w3cdbc78b9e82373c@mail.gmail.com> <3e8340490908131354q167840fcv124ec56c92bbb830@mail.gmail.com> <4A85E0DC.9040101@rtr.ca> <20090814234539.GE27148@parisc-linux.org> <1250341176.4159.2.camel@mulgrave.site> <4A86B69C.7090001@rtr.ca> <1250344518.4159.4.camel@mulgrave.site> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 15 Aug 2009 08:55:17 -0500 James Bottomley wrote: > On Sat, 2009-08-15 at 09:22 -0400, Mark Lord wrote: > > James Bottomley wrote: > > > > > > This means you have to drain the outstanding NCQ commands (stalling the > > > device) before you can send a TRIM. If we do this for every discard, > > > the performance impact will be pretty devastating, hence the need to > > > coalesce. It's nothing really to do with device characteristics, it's > > > an ATA protocol problem. > > .. > > > > I don't think that's really much of an issue -- we already have to do > > that for cache-flushes whenever barriers are enabled. Yes it costs, > > but not too much. > > That's not really what the enterprise is saying about flush barriers. > True, not all the performance problems are NCQ queue drain, but for a > steady workload they are significant. Flush barriers are nightmare for more than enterprise. You drive basically goes for a hike for a bit which trashes interactivity as well. If the device can't do trim and the like without a drain I don't see much point doing it at all, except maybe to wait for idle devices and run a filesystem managed background 'strimmer' thread to just weed out now idle blocks that have stayed idle - eg by adding an inode of all the deleted untrimmed blocks and giving it an irregular empty ? Alan