Subject: Re: PR/34293 CVS commit: src/sys/dev
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Michael van Elst <mlelstv@serpens.de>
List: netbsd-bugs
Date: 09/04/2006 05:25:02
The following reply was made to PR kern/34293; it has been noted by GNATS.

From: Michael van Elst <mlelstv@serpens.de>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: PR/34293 CVS commit: src/sys/dev
Date: Mon, 4 Sep 2006 07:22:32 +0200

 On Mon, Sep 04, 2006 at 09:26:22AM +0900, YAMAMOTO Takashi wrote:
 
 > > But if that is
 > > a problem, the feedback loop can be put into both vndread()/vndwrite().
 > 
 > why is it enough?
 
 It is not enough, but it catches the case where the device is
 accessed directly instead of through a filesystem.
 
 
 > > >  I suspect
 > > >  throttling the caller in vnd only hides the problem;
 > > 
 > > No, it prevents the problem. The writer needs to be throttled to
 > > not overwhelm the consumer because in this case it just eats up
 > > all memory. That necessary feedback loop is created by the patch.
 > 
 > can you explain how it prevents the problem while vndthread() already has
 > the same check?
 
 vndthread() does not have the same check. vndthread() is the consumer,
 you have to stop the producer that allocates all the buffers.
 
 
 > while vndthread is working on behalf of the pagedaemon here,
 > it is not a pagedaemon.  so it can't get special treatment for pagedaemon
 > from buffer cache etc and can deadlock.
 
 In my case it is definitely not working on behalf of the pagedaemon.
 
 
 Greetings,
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."