Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755591Ab0KSQVY (ORCPT ); Fri, 19 Nov 2010 11:21:24 -0500 Received: from mail-pw0-f46.google.com ([209.85.160.46]:61049 "EHLO mail-pw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755319Ab0KSQVX convert rfc822-to-8bit (ORCPT ); Fri, 19 Nov 2010 11:21:23 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=O7BGjG5O1R21A3TduIqFyXmomuhsbAaw/9X20HCkGD4ZayUc5iBG2CZpQuxjJAMEkf pn9il5UG8WcZ8zCEIUxRFcmxp7SR1f6ZwLDit+D0M0/wUurxhMamIdbj8bUoqpmqGKA5 8PTMcMwY/nBYw9WHixveDH6h5u6WcHhv+Vvbw= MIME-Version: 1.0 In-Reply-To: <20101119115516.GA1152@infradead.org> References: <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> <4CE5C616.7070706@teksavvy.com> <20101119115516.GA1152@infradead.org> From: Greg Freemyer Date: Fri, 19 Nov 2010 08:20:58 -0800 Message-ID: Subject: Re: [PATCH 1/2] fs: Do not dispatch FITRIM through separate super_operation To: Christoph Hellwig Cc: Mark Lord , "Martin K. Petersen" , James Bottomley , Jeff Moyer , Matthew Wilcox , Josef Bacik , Lukas Czerner , tytso@mit.edu, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, sandeen@redhat.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1898 Lines: 40 On Fri, Nov 19, 2010 at 3:55 AM, Christoph Hellwig wrote: > On Thu, Nov 18, 2010 at 05:16:36PM -0800, Greg Freemyer wrote: >> I agree with Mark. ?When you say "make coalescing work" it sounds like >> major overkill. >> >> FITRIM should be able to lock a group of non-contiguous free ranges, >> send them down to the block layer as a single pre-coalesced set, and >> the block layer just needs to pass it on in a synchronous way. ?Then >> when that group of ranges is discarded, FITRIM releases the locks. > > Given that you know the Linux I/O stack and hardware so well may I > volunteer you to implement it? ?Including remapping the multiple ranges > in device mapper, and dealing with the incompatible range formats for > TRIM vs UNMAP. ?If your implementation is clean enough I'm pretty > sure no one will object to merge it. > >> Every TRIM causes a cache flush anyway on the SSD, so the synchronous >> aspect of the process should not be a problem. ?(Maybe SCSI with thin >> provisioning would see a performance hit?) > > What's your evidence? The kernel team has been coding around some Utopian SSD TRIM implementation for at least 2 years with the basic assumption that SSDs can handle thousands of trims per second. Just mix em in with the rest of the i/o. No problem. Intel swore to us its the right thing to do. I'm still waiting to see the first benchmark report from anywhere (SSD, Thin Provisioned SCSI) that the online approach used by mount -o discard is a win performance wise. Linux has a history of designing for reality, but for some reason when it comes to SSDs reality seems not to be a big concern. Greg -- 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/