Messages in this thread | | | Date | Wed, 31 Mar 1999 16:39:26 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: buffer cache behavior on memory-constrained systems (fwd) |
| |
On Tue, 30 Mar 1999, Chuck Lever wrote:
>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/
| |