Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 10 Nov 2002 15:58:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 10 Nov 2002 15:58:28 -0500 Received: from 1-064.ctame701-1.telepar.net.br ([200.181.137.64]:63201 "EHLO 1-064.ctame701-1.telepar.net.br") by vger.kernel.org with ESMTP id ; Sun, 10 Nov 2002 15:58:27 -0500 Date: Sun, 10 Nov 2002 19:05:01 -0200 (BRST) From: Rik van Riel X-X-Sender: riel@imladris.surriel.com To: Andrew Morton cc: Andrea Arcangeli , Con Kolivas , linux kernel mailing list , Subject: Re: [BENCHMARK] 2.4.{18,19{-ck9},20rc1{-aa1}} with contest In-Reply-To: <3DCEC6F7.E5EC1147@digeo.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org 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: 1739 Lines: 43 On Sun, 10 Nov 2002, Andrew Morton wrote: > Andrea Arcangeli wrote: > > > > > Whether the IO is synchronous or asynchronous shouldn't matter much, > > > > the fact the I/O is sync or async makes the whole difference. with sync > > reads the vmstat line in the read column will be always very small > > compared to the write column under a write flood. This can be fixed either: > > > > 1) with hacks in the elevator ala read-latency that are not generic and > > could decrease performance of other workloads It'd be nice if you specified which kind of workloads. Generic handwaving is easy, but if you think about this problem a bit more you'll see that most workloads which look like they might suffer at first view should be just fine in reality... > read-latency will only do the front-insertion if it was unable to find a > merge or insert on the tail-to-head search. > > And the problem it desparately addresses is severe. Note that async-IO shouldn't make a big difference here, except maybe in synthetic benchmarks. This is because the stream of data in a server will be approximately the same regardless of whether the application is coded to use async IO, threads or processes and because clients still need to wait for the data on read while most writes are asynchronous. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Current spamtrap: october@surriel.com - 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/