17:51:28 < aki> http://lists.xensource.com/archives/html/xen-changelog/2006-08/msg00423.html
17:51:47 < aki> does anyone know what was the purpose of that aio context decrease ?
17:52:16 < icblenke> interesting find.
17:52:35 < aki> with aoe and a lot of io, like fsck or a dd, the callback that free the context is
called too late
17:53:00 < icblenke> did you increase your system-wide aio request limit?
17:53:02 < aki> and the domU crash when the pool is empty
17:53:12 < icblenke> echo echo 1048576 > /proc/sys/aio-max-nr
17:53:22 < icblenke> er, one echo.
17:53:26 < aki> well, blktap crashes
17:53:39 < aki> hm, no, it's the default, 64k
17:53:50 < icblenke> the patch spits out that message
17:53:58 < icblenke> try upping it.
17:54:03 < aki> yes, saw that
17:54:14 < aki> but the size of the pool is fixed per tapdisk process
17:54:29 < aki> the system wide setting only limits the number of running tapdisk processes
17:54:50 < icblenke> interesting.
17:54:53 < aki> and it's 352 by default on x86
17:55:01 < aki> for a 64k system wide max default ... :)
17:55:34 < icblenke> yeah, I don't see why they removed the *8, particularly if you're hitting the
limit.
17:55:50 < icblenke> probably due to people hitting the system limit
17:56:05 < icblenke> I'd put the *8 back in, and just up the system limit.
17:57:18 < aki> yeah, i think too
17:57:32 < aki> i've tested with MAX_SEGMENTS_PER_REQ = 32 before finding that patch
17:57:41 < aki> and it works just fine, even under heavy load