Dave Chinner <david@xxxxxxxxxxxxx> wrote: > On Sun, Dec 16, 2012 at 03:35:49AM +0000, Eric Wong wrote: > > Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > On Sun, Dec 16, 2012 at 12:25:49AM +0000, Eric Wong wrote: > > > > Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > On Sat, 15 Dec 2012 00:54:48 +0000 > > > > > Eric Wong <normalperson@xxxxxxxx> wrote: > > > > > > > > > > > Applications streaming large files may want to reduce disk spinups and > > > > > > I/O latency by performing large amounts of readahead up front > > > This could also be a use case for an audio/video player. > > Sure, but this can all be handled by a userspace application. If you > want to avoid/batch IO to enable longer spindown times, then you > have to load the file into RAM somewhere, and you don't need special > kernel support for that. >From userspace, I don't know when/if I'm caching too much and possibly getting the userspace cache itself swapped out. > > So no, there's no difference that matters between the approaches. > > But I think doing this in the kernel is easier for userspace users. > > The kernel provides mechanisms for applications to use. You have not > mentioned anything new that requires a new kernel mechanism to > acheive - you just need to have the knowledge to put the pieces > together properly. People have been solving this same problem for > the last 20 years without needing to tweak fadvise(). Or even having > an fadvise() syscall... fadvise() is fairly new, and AFAIK few apps use it. Perhaps if it were improved, more people would use it and not have to reinvent the wheel. > Nothing about low latency IO or streaming IO is simple or easy, and > changing how readahead works doesn't change that fact. All it does > is change the behaviour of every other application that uses > fadvise() to minimise IO latency.... I don't want to introduce regressions, either. Perhaps if part of the FADV_WILLNEED read-ahead were handled synchronously (maybe 2M?) and humongous large readaheads (like mine) went to the background, that would be a good trade off? -- 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>