hi,

On Tue, Jan 21, 2003 at 12:46:09PM +0900, enami tsugutomo wrote:
> Paul Ripke <stixpjr@ozemail.com.au> writes:
> > OK, so we aren't reserving enough memory for "emergency" use? Can the
> > kernel gods suggest a fix/workaround? I presume this relates to
> > NKMEMPAGES? Should I try increasing this? Or will that just postpone
> > the inevitable? So many questions...
> 
> IIRC, once chuq told that a driver at least should be able to handle
> one request without requiring more memory.  It might be true but it
> also might be difficult for some drivers like raid driver.

right, disk drivers must be able to make progress on write requests
even if there are no pages available from the VM system, since the
VM system uses disk driver writes to make more pages available.
this is true for all disk drivers, but most don't problem because they
use pools and so always have some memory for i/o descriptors cached
in the pool.  ideally each driver would have a low-water-mark set on
its pool(s) and deal with temporarily not being able to allocate a new
descriptor, eg. by waiting until some in-progress i/o completes.
not all (few? none?) of the drivers do this entirely correctly, but
in practice it's difficult to get most of them to fail as they stand now.

raidframe has a more difficult task than most other disk drivers
because it does more than just pass each i/o request as-is to the hardware,
but it must obey the same resource-allocation constraints as any other
disk driver if it is to avoid deadlock.


> BTW, currently pagedaemon stops initiating new pageout request if
> there is enough number of paging requrest ongoing.  Maybe we could do
> something to defer the catastrophe (e.g., clean page can be free'ed
> without writing to backing store).

the pagedaemon algorithm could be made more complex to possibly improve
responsiveness or efficiency, but this deadlock issue should be addressed
by fixing the disk drivers.

-Chuck