[lkml]   [1998]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Thread implementations...
Linus Torvalds writes:
> In article <>,
> Chris Wedgwood <> wrote:
> >On Wed, Jun 24, 1998 at 10:13:57PM +1000, Richard Gooch wrote:
> >
> >> If we get madvise(2) right, we don't need sendfile(2), correct?
> >
> >It would probably suffice. In fact, having a working implementation of
> >madvise, etc. would make sendfile pretty trivial to do in libc. (Again, I
> >assuming that whether or not we need it, if it can be implemented in
> >userspace then why not...)
> However, the thing to notice is that a "sendfile()" system call can
> potentially be a lot faster than anything else. In particular, it can
> be as clever as it wants about sending stuff directly from kernel
> buffers etc.
> I know there are a lot of people who think zero-copying is cool, and
> that tricks with mmap() etc can be used to create zero-copy. But don't
> forget that it's a major mistake to think that performance is about
> whether the algorithm is O(1) or O(n) or O(n^2). People tend to forget
> the constant factor, and look blindly at other things.
> In particular, doing a mmap() itself is fairly expensive. It implies a
> lot of bookkeeping, and it also implies a fair amount of mucking around
> with CPU VM issues (TLBs, page tables etc). In short, it can be rather
> expensive.
> Due to that expense, things that use mmap() often have a "cache" of
> mappings that they have active. Thet gets rid of one expense, but then
> there is the new expense of maintaining that cache (and it can be a
> fairly costly thing to maintain if you want to doa threaded webserver).
> In contrast, a "sendfile()" approach can be extremely light-weight, and
> threads much better because it doesn't imply the same kinds of
> maintenance.
> Now, I'm no NT person, but I suspect that we actually do want to have a
> "sendfile()" kind of thing just because it should be fairly easy to
> implement, and would offer some interesting performance advantages for
> some cases. No, it's not truly generic, but it is useful enough in many
> circustances.

Well, that's fine. I just hope that we get a better madvise(2) at some
point too.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:43    [W:0.114 / U:1.024 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site