--sm4nu43k4a2Rpi4c
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Update,

i've managed to reproduce the starvation problem with a kernel without any 
compilation flags apart from DIAGNOSTIC. When in starvation it seems to 
help to suspend the copy, create heaps of new nodes (using f.e. ls -alR on 
a big tree) and then continue with the copy. It looks like the problem is 
then gone for a while again.

My updated hypothosis is that for some reason vnode's buffers are not 
recycled in the right order when buffer space gets short.

Note that this is a kernel running with yamt's patch for genfs but since it 
uses iobufs and kernel memory is not exploding in size its very unlikely to 
be iobuf related unless its pool is set to low a high water mark.

Since the iobuf (and possibly also the normal buf pool?) are declared with 
a initialiser i dont know the min/max values. Could this be an issue? or am 
i rambling on this?

Or could your patch to genfs, Takashi, be confusing UVM? in ways my code 
didn't?

still puzzled,
Reinoud

--sm4nu43k4a2Rpi4c
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQ8MBCoKcNwBDyKpoAQKx8Qf9FfyC/y46ubQ3ZOjfLa2IpxfaRbzVudCS
5cNJm5vws6q/w1IV0eLJzR1jFx/guYjmPrVng0Ir+q8u6VijJshoaz6i00kPKJIG
AXhlJZbw5K0IjDtwnW8A2Ug2dFEOBh6ejfQ02QYZRDMyj31FVPLQnl8ErYor6ZJV
t2IWkPBaw9PpncFaayyOafvziv6QuwgdoMiMml3HkoC1dngGSZmkXS5uhj2ZuQxA
+IhJ29DUhVV+xNu7JDqZerWewm0Pfte90qX9rNmTNK6zHdCBmUqXm58gjnOPirZ3
9T8jq9yBh2yX6bmNr2QOav1AgbOQ/NAiNP5GYlmPDFfCgHJqYm7M2g==
=pglx
-----END PGP SIGNATURE-----

--sm4nu43k4a2Rpi4c--