> From: Andrea Arcangeli [mailto:aarcange@xxxxxxxxxx] > Sent: January 25, 2012 5:46 PM .... > Way more important is to have feedback on the readahead hits and be > sure when readahead is raised to the maximum the hit rate is near 100% > and fallback to lower readaheads if we don't get that hit rate. But > that's not a VM problem and it's a readahead issue only. > A quick google showed up - http://kerneltrap.org/node/6642 Interesting thread to follow. I haven't looked further as to what was merged and what wasn't. A quote from the patch - " It works by peeking into the file cache and check if there are any history pages present or accessed." Now I don't understand anything about this but I would think digging the file-cache isn't needed(?). So, yes, a simple RA hit-rate feedback could be fine. And 'maybe' for adaptive RA just increase the RA-blocks by '1'(or some N) over period of time. No more smartness. A simple 10 line function is easy to debug/maintain. That is, a scaled-down version of ramp-up/ramp-down. Don't go crazy by ramping-up/down after every RA(like SCSI LLDD madness). Wait for some event to happen. I can see where Andrew Morton's concerns could be(just my interpretation). We may not want to end up like a protocol state machine code: tcp slow-start, then increase , then congestion, then let's back-off. hmmm, slow-start is a problem for my business logic, so let's speed-up slow-start ;). Chetan -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href