On Thu, Feb 06, 2014 at 12:34, Mark Kettenis wrote:
> I believe the scenario you sketched should only land you in
> uvm_wait_pla(), but not in uvm_wait(). Perhaps with the current code
> we can end up in uvm_wait(), but I think those would be bugs where the
> driver I/O paths are doing memory all
> Date: Wed, 05 Feb 2014 23:03:09 -0500
> From: Ted Unangst
>
> On Wed, Feb 05, 2014 at 17:53, Bob Beck wrote:
> > On Wed, Feb 5, 2014 at 3:17 PM, Ted Unangst wrote:
> >> We are missing back pressure channels from uvm to the buf cache. The
> >> buf cache will happily sit on 9000 free pages while
Yes, this is much better. although I think this problem related to
big mmaps has been with us for a while.
and appears to avoid the problem with the offending test programs on
my machines.
I'm ok with that going in for the moment, although I want some of your
time to look at that nasty shit we t
On Wed, Feb 05, 2014 at 17:53, Bob Beck wrote:
> On Wed, Feb 5, 2014 at 3:17 PM, Ted Unangst wrote:
>> We are missing back pressure channels from uvm to the buf cache. The
>> buf cache will happily sit on 9000 free pages while uvm churns around
>> trying to scavenge up one more page.
> Or are you
On Wed, Feb 5, 2014 at 3:17 PM, Ted Unangst wrote:
> We are missing back pressure channels from uvm to the buf cache. The
> buf cache will happily sit on 9000 free pages while uvm churns around
> trying to scavenge up one more page.
Indeed, those are it's minimums (I presume in your case) and are
We are missing back pressure channels from uvm to the buf cache. The
buf cache will happily sit on 9000 free pages while uvm churns around
trying to scavenge up one more page.
Fixing this is beyond the scope of a simple diff, but here's something
that seems to help in a lot of the common cases, pa
