Messages in this thread | | | Date | Fri, 10 Oct 2003 11:05:35 -0700 | From | Joel Becker <> | Subject | Re: statfs() / statvfs() syscall ballsup... |
| |
On Fri, Oct 10, 2003 at 10:40:40AM -0700, Linus Torvalds wrote: > Actually, the kernel has a "readahead(fd, offset, size)" system call that > will start asynchronous read-ahead on any mapping. After that, just > touching the page will obviously map in and synchronize the result.
Ok, a quick peruse of sys_readahead() seems to say that it doesn't check for existing uptodate()ness. That would be interesting. I could have missed it, though.
> I don't think anybody uses it, and the interface may be broken, but it was > literally 20 lines of code, and I had a trivial test program that > populated the cache for a directory structure really quickly using it.
The problem we have with msync() and friends is not 'quick population', it's "page is in the page cache already; another node writes to the storage; must mark page as !uptodate so as to force a re-read from disk". I can't find where sys_readahead() checks for uptodate, so perhaps calling sys_readahead() on a range always causes I/O. Correct me if I missed it.
> For example, things we can do, but don't, partly because of interface > issues and because there is no point in doing it if people wouldn't use > it:
Lots of interesting stuff snipped. This discussion has me thinking, knowing now that there's possibility to move to a more optimal interface.
Joel
--
Life's Little Instruction Book #464
"Don't miss the magic of the moment by focusing on what's to come."
Joel Becker Senior Member of Technical Staff Oracle Corporation E-mail: joel.becker@oracle.com Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |