On Thu, Jul 3, 2014 at 11:11 AM, Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx> wrote: >> >> What? Where did you find that insane sentence? And where did you find >> an application that depends on that totally insane semantics that sure >> as hell was never intentional. >> >> If this comes from some man-page, > > Yes it is. Ok, googling actually finds a fairly recent patch to fix it http://www.spinics.net/lists/linux-mm/msg70517.html and several much older "that's not true" comments. I wonder how it ever happened, because it has never actually been true that readahead() has been synchronous. It *has* been true that large read-aheads have started so much IO that just the act of starting more would wait for request allocations etc to free up, so it's not like it has ever been entirely asynchonous either, but it definitely has *never* been synchronous afaik. The new behavior just means that you can't trigger the "request queues are all so full that we end up blocking waiting for new request allocations" quite as easily. That said, the bugzilla entry you mentioned does mention "can't boot 3.14 now". I'm not sure what the meaning of that sentence is, though. Does it mean "can't boot 3.14 to test it because the machine is busy", or is it a typo and really meant 3.15, and that some bootup script *depended* on readahead()? I don't know. It seems strange. It also seems like it would be very hard to even show this semantically (aside from timing, and looking at how much of the cache is used like the test-program does). So the bugzilla entry worries me a bit - we definitely do not want to regress in case somebody really relied on timing - but without more specific information I still think the real bug is just in the man-page. Linus -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>