On 2/18/20 1:21 PM, Matthew Wilcox wrote: > 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. > That is even worse than I initially thought. :) > 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 Yes, and now that you mention it, it's really tough to pick a single number that answers the right questions that the user space caller might have. whew. > meantime, let's just ditch the complexity and pretense that this number > means anything. > Definitely. Thanks for the notes here. thanks, -- John Hubbard NVIDIA
