In article <d8j08f$pt3$1@sea.gmane.org>, Jed Davis <jdev@panix.com> wrote:
> 
> And the other changes I'm making don't, so far as I know, sidestep this
> issue.  I think I'll have to chain the actual IOs together, toss them
> if a pool_get fails, run them all at the end of the segment loop, and
> adjust the xenshm callback to match.  Except that the callback can fail
> to install for want of memory, it looks like.  That's... annoying.

The resource-alllocation problem is even more fun than that.  It looks
as though, when the pool of xbdback_requests runs out -- and it will;
just create enough xbd's and throw enough IO at them -- any further
requests get the equivalent of EIO, whereas they should, I think, just
be left in the ring.  That on top of the xen_shm_callback thing.

Now, the Linux backend handles this by spinning off a kernel thread
to do the request-juggling; they don't have to care about blocking
allocation in that context, and indeed don't.  I don't know what the
NetBSD view on this sort of thing is.

Furthermore, the Linux backend accepts only a certain number (by
default, 16 out of a possible 64 pending; though, if they really
coalesce in the disksort-equivalent as they appear to, why not just do
one at a time?) of requests at once from a single domain -- i.e., a
simple round-robin arrangement -- presumably to keep one domain from
crowding out all the rest.

So... I'm a little lost on what to do about the flow control issue.

-- 
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k)))))))    '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))