Messages in this thread | | | From | "Adam Kropelin" <> | Subject | Re: [PATCH *] rmap VM 11c (RMAP IS A WINNER!) | Date | Sat, 19 Jan 2002 13:39:22 -0500 |
| |
Andrea Arcangeli: > On Sat, Jan 19, 2002 at 12:08:30AM -0500, Adam Kropelin wrote: > > /bin/echo "10 0 0 0 500 3000 30 0 0" > /proc/sys/vm/bdflush > ^ > > you cannot set the underlined one to zero (way too low, insane) or to > left it to its default (20) in -aa, or it will be misconfigured setup > that can lead to anything. the rule is: > > nfract_stop_bdflush <= nfract <= nfract_sync
<snip>
> so nfract_stop_bdflush cannot be 20.
Ok, thanks for straightening me out on that. I figured there might be some consequence of the additional knobs in -aa which I didn't know about.
> Furthmore you set ndirty to 0, that also is an invalid setup.
I didn't. That was one of the "additional parameters" that I left at the default on -aa (500, it seems). Sorry, I should have been clearer about exactly what settings I used on -aa; the quoted settings were for -rmap only. For reference, the exact command I tried on -aa was:
/bin/echo "10 500 0 0 500 3000 30 20 0" > /proc/sys/vm/bdflush
> With -aa something sane along the above lines is: > > /bin/echo "10 2000 0 0 500 3000 30 5 0" > /proc/sys/vm/bdflush
Unfortunately, those adjustments on top of 2.4.18-pre2aa2 set a new record for worst performance: 7:19.
An additional datapoint: The quoted bdflush settings which make 2.4.17-rmap11c a winner do not do well at all on 2.4.17-rmap11a. Rik's initial reaction to the issue was that there was a bug and I know he made some changes in rmap11c to address it. The fact that 11c definitely performs better for me than 11a seems to support this. Perhaps this bug or a variant thereof also exists in aa?
--Adam
- 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/
| |