Re: [CFT] delayed allocation and multipage I/O patches for 2.5.6.

From: Andrew Morton (akpm@zip.com.au)
Date: Mon Mar 18 2002 - 15:14:27 EST


Hanna Linder wrote:
>
> --On Monday, March 11, 2002 22:00:57 -0800 Andrew Morton <akpm@zip.com.au> wrote:
>
> > "help, help - there's no point in just one guy testing this" (thanks Randy).
>
> Will you accept the testing of a gal? ;)

With alacrity :) Thanks.

> >
> > This is an update of the delayed-allocation and multipage pagecache I/O
> > patches. I'm calling this a beta, because it all works, and I have
> > other stuff to do for a while.
> >
>
> Here are the dbench throughput results on an 8-way SMP with 2GB memory.
> These are run with 64 then 128 clients 15 times each averaged. It looked
> pretty good.
> Running with more than 180 clients caused the system to hang, after
> a reset there was much filesystem corruption. This happened twice. Probably
> related to filling up disk space.

It could be space-related. A couple of gigs should have been plenty..

One other possible explanation is to do with radix-tree pagecache.
It has to allocate memory to add nodes to the tree. When these
allocations start failing due to out-of-memory, the VM will keep
on calling swap_out() a trillion times without noticing that it
didn't work out. But if this happened, yo would have seen a huge
number of "0-order allocation failed" messages.

> There are no ServerRaid drivers for 2.5 yet
> so the biggest disks on this system are unusable. lockmeter results are forthcoming (day or two).
>
> Running dbench on an 8-way SMP 15 times each.
>
> 2.5.6 clean
>
> Clients Avg
>
> 64 37.9821
> 128 29.8258
>
> 2.5.6 with everything.patch
>
> Clients Avg
>
> 64 41.0204
> 128 30.6431
>

That's odd. I'm showing 50% increases in dbench throughput. Not
that there's anything particularly clever about that - these patches
allow the kernel to just throw more memory in dbench's direction, and
it likes that. But it does indicate that something funny is up.
I'll take a closer look - thanks again.

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



This archive was generated by hypermail 2b29 : Sat Mar 23 2002 - 22:00:16 EST