Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753291Ab0KSDog (ORCPT ); Thu, 18 Nov 2010 22:44:36 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.183]:60745 "EHLO ironport2-out.pppoe.ca" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751823Ab0KSDof (ORCPT ); Thu, 18 Nov 2010 22:44:35 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAIuB5UxLd/sX/2dsb2JhbAAHgz3MZJEDgSKDNnMEhFqLEIYI X-IronPort-AV: E=Sophos;i="4.59,221,1288584000"; d="scan'208";a="82946115" Message-ID: <4CE5F2A1.2000009@teksavvy.com> Date: Thu, 18 Nov 2010 22:44:33 -0500 From: Mark Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Ted Ts'o" , James Bottomley , Greg Freemyer , Jeff Moyer , Christoph Hellwig , Matthew Wilcox , Josef Bacik , Lukas Czerner , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, sandeen@redhat.com Subject: Re: [PATCH 1/2] fs: Do not dispatch FITRIM through separate super_operation References: <20101118134804.GN5618@dhcp231-156.rdu.redhat.com> <20101118141957.GK6178@parisc-linux.org> <20101118142918.GA18510@infradead.org> <1290100750.3041.72.camel@mulgrave.site> <1290102098.3041.77.camel@mulgrave.site> <4CE59E57.2090009@teksavvy.com> <1290117009.11007.42.camel@mulgrave.site> <4CE5A386.7000105@teksavvy.com> <20101119013301.GU3290@thunk.org> In-Reply-To: <20101119013301.GU3290@thunk.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1770 Lines: 38 On 10-11-18 08:33 PM, Ted Ts'o wrote: >>> >>> Before we go gung ho on this, there's no evidence that N discontiguous >>> ranges in one command are any better than the ranges sent N times ... >>> the same amount of erase overhead gets sent on SSDs. >> >> No, we do have evidence: execution time of the TRIM commands on the SSD. >> >> The one-range-at-a-time is incredibly slow compared to multiple >> ranges at a time. That slowness comes from somewhere, with about >> 99.9% certainty that it is due to the drive performing slow flash >> erase cycles. > > Mark, I think you are over-generalizing here. You have observed with > some number of flash drives --- maybe only one, but I don't know that > for sure --- that TRIM is slow. Even if we grant that you are correct > in your conclusion that it is because the drive is doing slow flash > erase cycles (and I don't completely accept that; I haven't seen your > your measurements since we know that any kind of command that requires > a queue drain/flush before it can execute is going to be slow, and I > don't know what kind of _slow_ you are observing). I do this stuff on modest hardware: ata_piix. There is NO QUEUE TO FLUSH. So one might expect TRIM to operate at the same speed as ordinary WRITEs. But it doesn't. When I measured this in detail (and things have not changed much since then), we were talking 10s of milliseconds to 100s of milliseconds per TRIM command. The only possible explanation for that would be waiting on flash erase commands. Cheers -- 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/