From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757654AbZHQRPU (ORCPT ); Mon, 17 Aug 2009 13:15:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757324AbZHQRPT (ORCPT ); Mon, 17 Aug 2009 13:15:19 -0400 Received: from mail.tmr.com ([64.65.253.246]:41379 "EHLO partygirl.tmr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756666AbZHQRPR (ORCPT ); Mon, 17 Aug 2009 13:15:17 -0400 Message-ID: <4A898FE4.1090104@tmr.com> Date: Mon, 17 Aug 2009 13:14:12 -0400 From: Bill Davidsen Organization: TMR Associates Inc, Schenectady NY User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090507 Fedora/1.1.16-1.fc9 SeaMonkey/1.1.16 MIME-Version: 1.0 To: jim owens CC: Mark Lord , Theodore Tso , Arjan van de Ven , Alan Cox , James Bottomley , 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) References: <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> <20090816150530.2bae6d1f@lxorguk.ukuu.org.uk> <20090816083434.2ce69859@infradead.org> <20090816154430.GE17958@mit.edu> <4A8841D7.10506@rtr.ca> <4A8843C3.3020409@rtr.ca> <4A8985B6.30103@tmr.com> <4A898BC4.70704@hp.com> In-Reply-To: <4A898BC4.70704@hp.com> 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 jim owens wrote: > Bill Davidsen wrote: >> >> I assume that it really is artificial, rather than the device really >> being ready for another operation (other than another TRIM). I lack >> the hardware, but the test would be the time to complete a read, trim >> and read, and two trim and read operations. Just my thought that the >> TRIM in progress may only block the next TRIM, rather than other >> operations. > > I don't know his test sequence but READ is not the likely command > before and after TRIM unless we are talking about TRIM being issued > only in delayed host garbage collection. Filesystems send WRITES > during delete. My idea is to test using a command which will definitely not need to prepare the media before completion, thus read. If TRIM doesn't block reads, then NCQ may allow reads to take place. Because of buffering slow reads hurt more than slow writes in terms of user perception. -- bill davidsen CTO TMR Associates, Inc "You are disgraced professional losers. And by the way, give us our money back." - Representative Earl Pomeroy, Democrat of North Dakota on the A.I.G. executives who were paid bonuses after a federal bailout.