Re: bad lmbench numbers for mmap

Linus Torvalds (torvalds@transmeta.com)
Sat, 17 Apr 1999 00:53:27 -0700 (PDT)


On Sat, 17 Apr 1999, Jakub Jelinek wrote:
>
> > I don't see that this problem should be anything new.
> > Have we ever been any good at lat_mmap?
>
> I have numbers that we have been. With 2.1.103 on a 167MHz Ultra1 I got 1505
> usec, with 2.2.5 on a 249MHz Ultra2 I got ~58000 usec. That's a huge
> difference.

Same lmbench binary? Hmm.. Would you mind testing it on the same machine
too, if at all possible?

Note that the number as reported by lmbench "summary" is meaningless, in
that it depends on how big a mmap you asked for. You can only compare
numbers between same-sized mmaps.

2.1.103 uses the same stupid write_page thing, except it has logic to
handle the case where the page is shared with the buffer cache. I removed
that logic because as far as I can tell it should never ever be hit
anyway - we no longer do the special "shared buffers page" thing.

If you have a 2.1.103 lying around somewhere, could you see if the "whee..
just mark the buffer heads dirty" case in filemap_write_page() in
mm/filemap.c ever actually triggers under it? As far as I can tell it
_shouldn't_ ever trigger (it's old code, from before we had the page cache
in the first place).

If that code triggers, then it would certainly explain the performance
difference. That's the old zero-copy code. However, I also think it's
broken if it does trigger, so..

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/