Andrea Arcangeli wrote:
>
> Only in 2.4.15aa1: 10_vm-17
> Only in 2.4.17pre1aa1: 10_vm-18
>
> Minor vm tweaks in function of the feedback received.
> Included Andrews' dirty += BUF_LOCKED.
>
OK. One think I notice is that you've also decreased nfract,nfract_sync
from (40%,60%) to (20%,40%). So taken together, these changes mean
that we'll start writeout much earlier, and will block writers much
earlier. What's the thinking here?
I received some interesting results from Mike Galbraith today.
Quoted without permission...
> 2.5.1-pre1
>
> This was initial test of effect on throughput at generic page
> mover load.. parallel make of kernel.
>
> real 7m54.873s
> user 6m41.070s
> sys 0m30.170s
>
> user : 0:06:47.35 72.6% page in : 661891
> nice : 0:00:00.00 0.0% page out: 708836
> system: 0:00:47.42 8.5% swap in : 140234
> idle : 0:01:46.26 18.9% swap out: 172775
>
> 2.5.1-pre1+vm-fixes
> real 7m48.438s
> user 6m41.070s
> sys 0m29.570s
>
> user : 0:06:47.89 74.9% page in : 666952
> nice : 0:00:00.00 0.0% page out: 621296
> system: 0:00:47.70 8.8% swap in : 142391
> idle : 0:01:28.94 16.3% swap out: 150721 * (free)
>
> (very interesting imho.. particularly idle time)
>
> 2.5.1-pre1+vm-fixes+elevator
> real 8m13.386s
> user 6m38.330s
> sys 0m31.680s
>
> user : 0:06:45.24 70.3% page in : 596724
> nice : 0:00:00.00 0.0% page out: 574456
> system: 0:00:47.79 8.3% swap in : 123507
> idle : 0:02:03.64 21.4% swap out: 138675
>
> (free for this load)
>
> 2.5.1-pre1+vm-fixes+elevator+mini-ll
> real 8m12.437s
> user 6m38.860s
> sys 0m31.680s
>
> user : 0:06:45.90 71.0% page in : 604385
> nice : 0:00:00.00 0.0% page out: 572588
> system: 0:00:47.50 8.3% swap in : 126731
> idle : 0:01:58.05 20.7% swap out: 138055
So we see that the dirty += BUF_LOCKED thing appears to
increase the parallel-make-on-64meg-machine workload.
Unfortunately the vm-fixes patch also has a few tweaks
to decrease swapout and eviction, and we can see from Mike's
numbers that the page in/out rate has dropped quite a bit.
So we don't know which change caused the (rather modest)
throughput improvement.
We also see that the elevator read latency improvements
have caused a 5%-6% drop in throughput, which is to be
expected. Tuning that back with `elvtune -b' will presumably
get the aggregate throughput back, at the expense of interactivity.
Generally, your VM patch is getting really, really large,
Andrea. This is a bit awkward, because we're twiddling so
many knobs at the same time, and there's not a lot of description
about what all the bits do. Is it possible to break it up
into smaller units? What are your plans for sending this
patch to Marcelo?
Thanks.
-
-
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 : Fri Nov 30 2001 - 21:00:35 EST