Messages in this thread | | | Date | Fri, 10 Oct 2003 20:31:01 +0200 | From | Andrea Arcangeli <> | Subject | Re: statfs() / statvfs() syscall ballsup... |
| |
On Fri, Oct 10, 2003 at 11:05:35AM -0700, Joel Becker wrote: > thinking, knowing now that there's possibility to move to a more optimal > interface.
cleaner and simpler could very well be (many simpler db works that way infact), but more optimal I doubt. To be more optimal you should let the kernel do all the garbage collection of mappings, and not use remap_file_pages. But then I'm unsure if the kernel is really able better than you to choose what info to discard from the cache, and you'd still have to pay for page faults that you don't have to right now.
And if you use remap_file_pages to still choose what to ""discard first"" from userspace, then you'd better use O_DIRECT instead, that doesn't require any pte mangling (ignoring the readahead, async-io and msync, scsi-shared issues that sounds fixable).
About the security issues, they existed in older kernels they're nowadays fixed thanks to Stephen's i_alloc_sem.
though, I'd be interesting to compared different models in practice to be sure, I just don't have expectations for it being a "more optimal" design at the moment.
Andrea - If you prefer relying on open source software, check these links: rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/ http://www.cobite.com/cvsps/ - 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/
| |