(2013/11/20 0:02), Christoph Badura wrote:
After updating my -current kernel from 6.99.24 to 6.99.27 so I could
commit my ubsec(4) changes I noticed that under 6.99.27 I get between
3 and 8 percent less throughput on accelerated crypto ops.
Note that I am using the exact same ubsec(4) code[1] wi
> I would like to change the way vmem(9) allocates boundary tags towards
> using a pool(9) for that.
>
> This de-duplicates code and makes it possible to release memory pages
> used for boundary tags.
>
> early patch any comments?
i fear adding another way that vmem and pool can loop, ala my
po
Hi,
I would like to change the way vmem(9) allocates boundary tags towards
using a pool(9) for that.
This de-duplicates code and makes it possible to release memory pages
used for boundary tags.
early patch any comments?
Lars
Index: sys/kern/subr_vmem.c
On Tue, 19 Nov 2013, Christoph Badura wrote:
> On Mon, Nov 18, 2013 at 12:31:41PM +1100, matthew green wrote:
> > i would buy this argument if mmap()ing a large sparse file
> > and filling it up randomly (but with relatively large chunks
> > at a time) did not lead to severely fragmented files tha
After updating my -current kernel from 6.99.24 to 6.99.27 so I could
commit my ubsec(4) changes I noticed that under 6.99.27 I get between
3 and 8 percent less throughput on accelerated crypto ops.
Note that I am using the exact same ubsec(4) code[1] with both kernels, so
I think it is unlikely a
On Mon, Nov 18, 2013 at 12:31:41PM +1100, matthew green wrote:
> i would buy this argument if mmap()ing a large sparse file
> and filling it up randomly (but with relatively large chunks
> at a time) did not lead to severely fragmented files that
> can take 10x to read, vs one written with plain se
On Fri, Nov 01, 2013 at 01:06:07PM -0400, Greg Troxel wrote:
> This patch to netbsd-5 adds pps support to ucom(4), which should enable
> pps on all usb serial chips that report modem control changes.
> [...]
> I am inclined to port this change to -current, compile-test it, and
> commit it. Objecti
The attached diff will:
Replace VI_INACTNOW and VI_INACTREDO with a new flag VI_CHANGING that gets
set while a vnode changes state from active to inactive or from active
or inactive to clean and protects "vclean(); vrelel()" and "vrelel()"
against "vget()".
Comments or objections anyone?
--
J. H
