On Wednesday 24 January 2001 09:44, Jens Axboe wrote:
> On Wed, Jan 24 2001, Steven Cole wrote:
> > > Thanks! Could I talk you into doing one last run? pre8 with
> > > include/linux/elevator.h having these values set for
> > > ELEVATOR_LINUS:
> >
> > Here are two sets of dbench 48 runs with that m
On Wed, Jan 24 2001, Steven Cole wrote:
> > Thanks! Could I talk you into doing one last run? pre8 with
> > include/linux/elevator.h having these values set for
> > ELEVATOR_LINUS:
> >
> Here are two sets of dbench 48 runs with that mod. I can't explain why the
> second set is faster. The second
On Tuesday 23 January 2001 13:54, Jens Axboe wrote:
>
> Thanks! Could I talk you into doing one last run? pre8 with
> include/linux/elevator.h having these values set for
> ELEVATOR_LINUS:
>
Here are two sets of dbench 48 runs with that mod. I can't explain why the
second set is faster. The secon
On Tue, Jan 23 2001, Steven Cole wrote:
> In the following table, 2.4.1-pre8x refers to -pre8 with
> linux/include/linux/blkdev.h modified as suggested.
> A diff to show the changes made is included at the end.
>
> Here is a summary of the data, followed by the data
> for the individual runs. Ea
On Monday 22 January 2001 16:11, Jens Axboe wrote:
>
> Stephen,
>
> To rule out other factors, could you try 2.4.1-pre8 with
> blk_started_io() and blk_finished_io() defined to nothing
> in include/linux/blkdev.h? This will disable the max-locked-buffers
> heuristic.
>
> Also, are the numbers abov
On Mon, Jan 22 2001, Marcelo Tosatti wrote:
>
> Jens,
>
> Steven is a seeing a slowdown in his results, too.
>
>
> On Mon, 22 Jan 2001, Steven Cole wrote:
>
> > On Thursday 18 January 2001 14:49, Marcelo Tosatti wrote:
> >
> > > Steven,
> > >
> > > The issue is the difference between pre4
Jens,
Steven is a seeing a slowdown in his results, too.
On Mon, 22 Jan 2001, Steven Cole wrote:
> On Thursday 18 January 2001 14:49, Marcelo Tosatti wrote:
>
> > Steven,
> >
> > The issue is the difference between pre4 and pre8.
> >
> > Could you please try pre4 and report results ?
> >
>
On Fri, 19 Jan 2001, Jens Axboe wrote:
> On Fri, Jan 19 2001, Szabolcs Szakacsits wrote:
> > Redone with big enough swap by requests.
> > 2.4.0,132MB swap
> > 548.81user 128.97system11:22 99%CPU (442433major+705419minor)
> > 561.12user 171.06system12:29 97%CPU (446949major+712525minor)
On Fri, Jan 19 2001, Szabolcs Szakacsits wrote:
>
> Redone with big enough swap by requests.
>
> 2.4.0,132MB swap
> 548.81user 128.97system11:22 99%CPU (442433major+705419minor)
> 561.12user 171.06system12:29 97%CPU (446949major+712525minor)
> 625.68user 2833.29system 1:12:38 79%CPU (
On Fri, Jan 19 2001, Andi Kleen wrote:
> Shouldn't it more depend on the bandwidth/latency of the IO device?
Not really they should just make sure that we don't lock down
all buffers. The low water mark is just to make sure we don't
wake up readers/writers right after having blocked them.
--
*
Redone with big enough swap by requests.
2.4.0,132MB swap
548.81user 128.97system11:22 99%CPU (442433major+705419minor)
561.12user 171.06system12:29 97%CPU (446949major+712525minor)
625.68user 2833.29system 1:12:38 79%CPU (638957major+1463974minor)
===
2.4.1pre8,132MB swap
548
On Fri, Jan 19, 2001 at 02:47:45AM +0100, Jens Axboe wrote:
> On Fri, Jan 19 2001, Andi Kleen wrote:
> > > Yes I agree, that values should probably be tweaked a bit. I'll
> > > try and squeeze some testing in to generate the best possible
> > > values.
> >
> > Please also add a sysctl. I always f
On Fri, Jan 19 2001, Andi Kleen wrote:
> > Yes I agree, that values should probably be tweaked a bit. I'll
> > try and squeeze some testing in to generate the best possible
> > values.
>
> Please also add a sysctl. I always feel uncomfortable with such hardcoded
> heuristics. There tends to be al
On Thu, Jan 18 2001, Marcelo Tosatti wrote:
> > Marcelo can you give a try with `high_queued_sectors = total_ram / 3' and
> > low_queued_sectors = high_queued_sectors / 2 and drop the big ram machine
> > check?
>
> Andrea,
>
> With the changes you suggested I got almost the same results with
> p
On Fri, Jan 19, 2001 at 02:40:23AM +0100, Jens Axboe wrote:
> On Fri, Jan 19 2001, Andrea Arcangeli wrote:
> > On Thu, Jan 18, 2001 at 03:17:13PM -0200, Marcelo Tosatti wrote:
> > > Jens, can be the -blk patch the reason for the slowdown I'm seeing?
> >
> > This heuristic is way too aggressive:
>
On Fri, 19 Jan 2001, Andrea Arcangeli wrote:
> Marcelo can you give a try with `high_queued_sectors = total_ram / 3' and
> low_queued_sectors = high_queued_sectors / 2 and drop the big ram machine
> check?
Andrea,
With the changes you suggested I got almost the same results with
pre8.
-
To
On Fri, Jan 19 2001, Andrea Arcangeli wrote:
> On Thu, Jan 18, 2001 at 03:17:13PM -0200, Marcelo Tosatti wrote:
> > Jens, can be the -blk patch the reason for the slowdown I'm seeing?
>
> This heuristic is way too aggressive:
>
> /*
>* Try to keep 128MB max hysteris. If not possibl
On Thu, Jan 18, 2001 at 03:17:13PM -0200, Marcelo Tosatti wrote:
> Jens, can be the -blk patch the reason for the slowdown I'm seeing?
This heuristic is way too aggressive:
/*
* Try to keep 128MB max hysteris. If not possible,
* use half of RAM
*/
high_
On Thu, 18 Jan 2001, Steven Cole wrote:
> On Thu, 18 Jan 2001, Marcelo Tosatti wrote:
> > On my dbench runs I've noted a slowdown between pre4 and pre8 with 48
> > threads. (128MB, 2 CPU's machine)
>
> I ran dbench 48 four times in succession for 2.4.0 and 2.4.1-pre8.
> The change in performan
On Thu, 18 Jan 2001, Marcelo Tosatti wrote:
> On my dbench runs I've noted a slowdown between pre4 and pre8 with 48
> threads. (128MB, 2 CPU's machine)
I ran dbench 48 four times in succession for 2.4.0 and 2.4.1-pre8.
The change in performance appears to be not significant.
This was performed w
On Thu, 18 Jan 2001, Marcelo Tosatti wrote:
> On my dbench runs I've noted a slowdown between pre4 and pre8 with 48
> threads. (128MB, 2 CPU's machine)
Below some kernel compile numbers on a 32 MB RAM + 32 MB swap box. The
three lines mean compilation with the -j1, -j2 and -j4 option. Most of
t
21 matches
Mail list logo
