On Tue, Feb 18, 2020 at 01:05:29PM -0800, John Hubbard wrote: > This is an easy review and obviously correct, so: > > Reviewed-by: John Hubbard <jhubbard@xxxxxxxxxx> Thanks > Thoughts for the future of the API: > > I will add that I could envision another patchset that went in the > opposite direction, and attempted to preserve the information about > how many pages were successfully read ahead. And that would be nice > to have (at least IMHO), even all the way out to the syscall level, > especially for the readahead syscall. Right, and that was where I went initially. It turns out to be a non-trivial aount of work to do the book-keeping to find out how many pages were _attempted_, and since we don't wait for the I/O to complete, we don't know how many _succeeded_, and we also don't know how many weren't attempted because they were already there, and how many weren't attempted because somebody else has raced with us and is going to attempt them themselves, and how many weren't attempted because we just ran out of memory, and decided to give up. Also, we don't know how many pages were successfully read, and then the system decided to evict before the program found out how many were read, let alone before it did any action based on that. So, given all that complexity, and the fact that nobody actually does anything with the limited and incorrect information we tried to provide today, I think it's fair to say that anybody who wants to start to do anything with that information can delve into all the complexity around "what number should we return, and what does it really mean". In the meantime, let's just ditch the complexity and pretense that this number means anything.
