From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Lord Subject: Re: Discard support (was Re: [PATCH] swap: send callback when swap slot is freed) Date: Sat, 15 Aug 2009 09:22:36 -0400 Message-ID: <4A86B69C.7090001@rtr.ca> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1250341176.4159.2.camel@mulgrave.site> Sender: linux-ide-owner@vger.kernel.org To: James Bottomley Cc: 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 List-Id: linux-raid.ids 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. The current problem is that the only existing SSDs in the wild with TRIM, take 100s of milliseconds per TRIM, mostly regardless of the amount being TRIMmed. Sure, some TRIMs take only 10-20ms, and very large ones (millions of sectors) can take 1-2 seconds, but most are in the 100ms range. Cheers From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51]) by kanga.kvack.org (Postfix) with SMTP id D26996B004F for ; Sat, 15 Aug 2009 09:22:30 -0400 (EDT) Message-ID: <4A86B69C.7090001@rtr.ca> Date: Sat, 15 Aug 2009 09:22:36 -0400 From: Mark Lord MIME-Version: 1.0 Subject: Re: Discard support (was Re: [PATCH] swap: send callback when swap slot is freed) 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> In-Reply-To: <1250341176.4159.2.camel@mulgrave.site> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: James Bottomley Cc: 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 List-ID: 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. The current problem is that the only existing SSDs in the wild with TRIM, take 100s of milliseconds per TRIM, mostly regardless of the amount being TRIMmed. Sure, some TRIMs take only 10-20ms, and very large ones (millions of sectors) can take 1-2 seconds, but most are in the 100ms range. Cheers -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org