Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 24 Sep 2002 17:13:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 24 Sep 2002 17:13:13 -0400 Received: from tmr-02.dsl.thebiz.net ([216.238.38.204]:56840 "EHLO gatekeeper.tmr.com") by vger.kernel.org with ESMTP id ; Tue, 24 Sep 2002 17:13:12 -0400 Date: Tue, 24 Sep 2002 17:10:54 -0400 (EDT) From: Bill Davidsen To: Jens Axboe cc: Andrew Morton , lkml , "linux-mm@kvack.org" Subject: Re: 2.5.38-mm2 In-Reply-To: <20020923071633.GA15479@suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1308 Lines: 32 On Mon, 23 Sep 2002, Jens Axboe wrote: > Ah interesting. I do still think that it is worth to investigate _why_ > both elevator_linus and deadline does not prevent the read starvation. > The read-latency is a hack, not a solution imo. > > > tagged command queueing on scsi - it appears to be quite stupidly > > implemented. > > Ahem I think you are being excessively harsh, or maybe passing judgement > on something you haven't even looked at. Did you consider that you > _drive_ may be the broken component? Excessive turn-around times for > request when using deep tcq is not unusual, by far. I do think that's what he meant! I think most drives are optimized this way, and performance would be better if the kernel used the queueing more sparingly, so the drive couldn't just run with the writes and let the reads take the leftovers. I think that's a better long run solution, although the fix addresses the immediate problem. -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - 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/