> It _would_ perhaps be interesting to see if it is worthwhile to change the
> sendfile() interface to do the open-close inside sendfile, and pass
> sendfile a filename. The reason I didn't do that is that I suspect that
> any real use of sendfile() would have to open the file for other reasons
> anyway (to do a "stat" on it to get modification times, for example) and
> in that case it would be a bad interface to require us to do another name
> lookup.
i was thinking about this one too, and here are a couple of
counter-arguments:
- it's less generic since it ties two operations which do not have much
'synergy' effects
- even if Apache does only one operation on the file descriptor (in the
fast path), on proxies we have to open once, and do multiple operations on
the same file descriptor. We might do fast dentry lookups, but we cannot
beat the speed of an array lookup. [when doing it more than once]
- (Dean's argument, i didnt think of this one but it's probably the most
powerful argument, the mapping between names and file descriptors is not
identical to the kernel's name space in the Apache case. Thus Apache
would have to filter out it's "own" mappings first, and let the kernel do
the second mapping)
but there is one argument for doing a name-based lookup in sendfile() too:
- there _are_ synergy effects. Most notably, sendfile() does not have to
follow the 'get me the smallest file descriptor number' rule when opening
a file for internal use. And the cost of doing the (logical) open/close
within the kernel is lower. (i dont think we could go to the dentry/inode
level easily, we want to have readahead within sendfile() too)
I think the counter-arguments are devastating, and in the future, with a
new feature, we might get the open/close speedup by letting users open
non-smallest-fd files too. At first sight this requires some kind of
per-task 'reusable file numbers' linked list, but is i think quite
nontrivial, it brings up the same kind of memory usage problems as we see
with dentries. It would be a flag to open(), which says
'O_DONT_CARE_WHAT_NUMBER_I_GET'. This still preserves the old Unix
semantics for say binary Apache modules, but gets us do O(1) & low-latency
open() even if there are thousands of files open. Dean, would this help
Apache, or am i overlooking something?
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu