Subject: Re: NEWPIPE: benchmark performance diff microtime(9) vs. =
To: Jaromir Dolecek <firstname.lastname@example.org>
From: Alfred Perlstein <email@example.com>
Date: 10/25/2001 19:45:59
* Jaromir Dolecek <firstname.lastname@example.org> [011025 17:11] wrote:
> Alfred Perlstein wrote:
> > What about arches that have 16k pages or something? I know the
> > 8192 is ugly, but it sort of makes sense as a hardcoded value
> > rather than using some arbitrary multiple of PAGE_SIZE.
> Well, the basic idea is that it doesn't seem to make too much sense
> to loan piece of memory < PAGE_SIZE (Page Loan works by pages).
> That's why I used PAGE_SIZE as basic atom. More recent tests
> show up that the overhead of Page Loan setup seems to still
> be higher than the gain for i386 page size (4k), so bumping it
> to higher value is desirable.
> It _may_ make more sense to just use hardcoded value. One issue
> to consider is that the pages is marked COW while loaned.
> If the pipe buffer only takes part of the buffer, some other
> thread might touch other part of memory which happens to be on
> same page and cause a page fault. This could eliminate quite
> a big part of performance gain of page loan. At least this is
> a theory I have :)
Yes, but in the case of 16k pages, you must write at least
32k to take advantage of it. On arches where page size is
only 8k you need a 16k write, 8k just sounds right. :)
Honestly it's really bogus to assert anything without having the
numbers available, have you done any timings of what happens on
arches with smaller/bigger page sizes when faced with 8k < write_size
< 2*PAGE_SIZE writes versus just 8k < write_size?
> > Btw, if you wouldn't mind sharing, what would make this faster
> > than FreeBSD's version? The optimized timestamp? Or is there
> > something else FreeBSD can learn from your implementation?
> Not much. The current performance gain on NetBSD is merely
Ok, thanks for explaining that.
-Alfred Perlstein [email@example.com]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'