>i've played around with 2.2.4-arca3 a little more. it works nicely on
>machines with fast disks (i.e. there is a bigger bottleneck somewhere else
>besides disk speed). however, it seems like on machines with slow disks,
Note that also that I released a 2.2.5_andrea1.bz2 that seems to have
great VM improvements here compared to 2.2.4_arca*. But it's still a
middle way of what I am doing now with a two level lru needed to completly
preserve the working set.
>the same cache size tuning behavior doesn't work as well. i'm wondering
>if there is any way to factor in relative disk bandwidth, or whether it is
>impractical/impossible to tune a machine with limited physical memory and
>a wide gap in CPU/disk performance?
Well I think to know the cause of the slowdown pretty well. Some month ago
at 2.2.0-pre time I was wrong thinking that to get performances we would
need stable swapin/swapout numbers over the time, it's exactly the
opposite (I discovered this these days). The problem of my current code in
slow HD is that it doesn't first swapin and then swapout but it
swapin/swapout at the same time in a mixed fascion: the so/si numbers are
constant over the time (could you confirm that?). So if the disk is slow
the seek time caused by swapin during swapout hurts too much. I had great
improvement in some experimental/unofficial VM I developed here (from
80sec to 33sec) changing some bit of code exactly for this reason. Fixing
this according to me should fix everything.
>my observations show that on machines with such wide gaps, the system
>slowly oscillates between good performance and all processes blocked. this
True, but I don't think we can do a lot to avoid such blocked processes.
The problem is that you could swap less and be more aggressive against the
cache, but we'll find oursef eating the working set. So I don't think we
can do a lot... Comments?
>suggests that tuning might help even out performance; that is, that this
>kind of machine can perform better.
>
>also, i think the page LRU approach is a clever way to solve the buffer
>reclamation problem. do you know how close to optimal (in terms of
Very happy to hear that ;).
>keeping the most used buffers in memory, and expelling the least used
>ones) it is?
It should be optimal according to my instinct, but I didn't do math on
it...
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/