Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262337AbUC1SWN (ORCPT ); Sun, 28 Mar 2004 13:22:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262335AbUC1SWN (ORCPT ); Sun, 28 Mar 2004 13:22:13 -0500 Received: from mion.elka.pw.edu.pl ([194.29.160.35]:52921 "EHLO mion.elka.pw.edu.pl") by vger.kernel.org with ESMTP id S262337AbUC1SVJ (ORCPT ); Sun, 28 Mar 2004 13:21:09 -0500 From: Bartlomiej Zolnierkiewicz To: William Lee Irwin III , Jens Axboe Subject: Re: [PATCH] speed up SATA Date: Sun, 28 Mar 2004 20:30:11 +0200 User-Agent: KMail/1.5.3 Cc: Jeff Garzik , Nick Piggin , linux-ide@vger.kernel.org, Linux Kernel , Andrew Morton References: <4066021A.20308@pobox.com> <20040328175436.GL24370@suse.de> <20040328181223.GA791@holomorphy.com> In-Reply-To: <20040328181223.GA791@holomorphy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403282030.11743.bzolnier@elka.pw.edu.pl> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1659 Lines: 28 On Sunday 28 of March 2004 20:12, William Lee Irwin III wrote: > On Sun, Mar 28, 2004 at 07:54:36PM +0200, Jens Axboe wrote: > > Sorry, but I cannot disagree more. You think an artificial limit at the > > block layer is better than one imposed at the driver end, which actually > > has a lot more of an understanding of what hardware it is driving? This > > makes zero sense to me. Take floppy.c for instance, I really don't want > > 1MB requests there, since that would take a minute to complete. And I > > might not want 1MB requests on my Super-ZXY storage, because that beast > > completes io easily at an iorate of 200MB/sec. > > So you want to put this _policy_ in the block layer, instead of in the > > driver. That's an even worse decision if your reasoning is policy. The > > only such limits I would want to put in, are those of the bio where > > simply is best to keep that small and contained within a single page to > > avoid higher order allocations to do io. Limits based on general sound > > principles, not something that caters to some particular piece of > > hardware. I absolutely refuse to put a global block layer 'optimal io > > size' restriction in, since that is the ugliest of policies and without > > having _any_ knowledge of what the hardware can do. > > How about per-device policies and driver hints wrt. optimal io? Yep, user-tunable per-device policies with sane driver defaults. - 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/