* Jaromir Dolecek <jdolecek@netbsd.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
[snip]

Ok, thanks for explaining that.

-- 
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
                           http://www.morons.org/rants/gpl-harmful.php3