Le 29-Mar-2000, Bryan -TheBS- Smith écrivait :
> Run-Time Tweaks (/proc filesystem):
>
> /proc/sys/vm/bdflush
>
> It takes 9 parameters (6 used -- 2.2.14 default in ()'s ):
> 1) Percentage of DB cache before fluishing (40)
> 2) Maximum # of DB to write per flush (500)
> 3) Number of clean buffers per refill (64)
> 4) DB refill threshold before flushing (256)
> 5) UNUSED (500)
> 6) Maximum DB age before flush (3000)
> 7) Maximum superblock DB age before flush (500)
> 8) UNUSED (1884)
> 9) UNUSED (2)
Looking at 2.2.x kernel sources, it seems that :
- nrefill and nref_dirty (3 and 4) are now dummies :) I couldn't find any code
using them.
- 5 is not really unused; It's called "interval" internally and is "the number
of jiffies between kflushd wakeups".
> E.g.:
> echo "25 50 64 256 500 1000 100 1884 2" > /proc/sys/vm/bdflush
>
> [ The above is what I am running with now, seems to have removed
> the massive disk writes I was previously experiencing on a
> server with 1GB of RAM. ]
That looks great!
- You lowered the maximum % of the buffer that should be dirty. This may lower
a little bit the write performance (keeping dirty buffers around helps write
coalescing, but with large memory you may not need very big % to get most of
this effect anyway). On the other side, it helps avoiding "write floods", and
lowers the amount of "locked" (well, write pending) memory in buffer.
- But what I think really made the difference, you lowered the "ndirty"
parameter (2nd) by a large amount, so much in fact that it is now below
NR_REQUEST (128); Now bdflush/kflushd cannot totally flood the request
queue with writes anymore. Does that use more CPU ? At least I don't think it
hurts the write bandwidth, because if I understand well, kflushd now loops 'til
the % of dirty buffers is below ndirty anyway...
Maybe kflushd should work "hand in hand" with the request buffer to keep it
busy, but try not to flood it ?
-
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/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:14 EST