lkml.org 
[lkml]   [1998]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Thread implementations...


On 27 Jun 1998, Andi Kleen wrote:
>
> But how does it look if you compare it to something that uses mmap() ?
> On my machine GNU cp always seems to use read/write for copying.

Quite frankly, I'd be _very_ surprised if mmap() wins, but I'll test.

[ .. time passes .. ]

mmap() did the same 38MB file in 1.11, about 2-3% slower than sendfile(),
but certainly faster than read()+write() (to refresh your memories
read+write took 1.58, sendfile took 1.08sec). However, this is the
absolutely best case for mmap - one large write of something in the cache,
where the overhead of doing the map can be ignored. And mmap() lost.

I then did a test of doing a much smaller file: sending the same (much
smaller) file 10000 times. mmap() took 0.82 seconds for the file I tried,
sendfile() took 0.69 sec. That's almost 20% slower.

Final test: I did the same thing with just 10000 write() calls (by the
logic that it was the only thing that was common between mmap() and
sendfile(), and was a kind of "perfect" result when ignoring the read
side). That took 0.64 seconds.

Note that with mmap(), under absolutely perfect circumstances, you could
imagine doing the mmap() just once, and then doing 10000 writes. So
assuming that (a) you have the perfect case and (b) you have no overhead
for looking up whatever mmap cache you use, then yes, there is a case
where mmap() would have performed better (the 0.69 vs 0.64 second
number). I don't think that is very likely load..

Also, Ingo pointed out that if you do threading and SMP, then mmap()
performance wilts completely. Because at that point mmap() starts to need
to do CPU cross-calls when it does TLB flushes (the same mapping exists on
both CPU's, because you have multiple threads sharing it), and now you're
really screwed.

Trust me, mmap() is a loss. It's losing even under normal load, on
high-end hardware with threads it isn't even a contest.

Linus


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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