Message-ID: <3EB168A3.4060207@cyberone.com.au>
Date: Fri, 02 May 2003 04:34:11 +1000
From: Nick Piggin <piggin@cyberone.com.au>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4
MIME-Version: 1.0
To: tomlins@cam.org
CC: Andrew Morton <akpm@digeo.com>, linux-kernel@vger.kernel.org
Subject: Re: [BENCHMARK] 2.5.68-mm3 with contest
References: <fa.i2rq9k6.40evjg@ifi.uio.no> <fa.hp8a369.1t0qqpt@ifi.uio.no> <20030501115221.A85BC11B0B@oscar.casa.dyndns.org>
In-Reply-To: <20030501115221.A85BC11B0B@oscar.casa.dyndns.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1017
Lines: 27

Ed Tomlinson wrote:

>Andrew Morton wrote:
>
>
>>Con Kolivas <kernel@kolivas.org> wrote:
>>
>>>All the io-write based loads were affected.
>>>
>>Yup.  Mainly because the large queue increases truncate latencies.
>>
>
>Are there loads that do benefit from large queues?  If so, does it make
>sense to use truncate impact (something like a decaying average of truncate
>time per interval) to control the size of the queues on the fly?
>
I'll post some more benchmarks, but I have found that loads with
lots of IO streams. Those with more than about 1/2 as many IO streams
as request slots start to show improvements. I don't think changing
the size of the queues on the fly would be any good. They can be
made runtime tunable quite easily now, which is a good bad solution.

-
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/