From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4af4fdc2ab262bb8487646699ef24bae@quanstro.net>
To: mattmobile@proweb.co.uk, 9fans@9fans.net
From: erik quanstrom <quanstro@quanstro.net>
Date: Mon, 14 Jul 2008 10:24:31 -0400
In-Reply-To: <487A7FB0.7080009@proweb.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] offtopic: winaoe
Topicbox-Message-UUID: e4b92a74-ead3-11e9-9d60-3106f5b1d025

> erik quanstrom wrote:
>>> I'm serving drives to WinXP64 via AOE with http://winaoe.org/

i've been ignoring this driver.  i'm worthless at windows.
(it's the small blessings, right?)  but now that i've taken
a look, i naively wonder about some things.

i think i see why syscalls take so long when a device has gone
missing.  the thread Thread (seems to be roughly a kproc?) doesn't
appear to have a sleep in it so it ends up grabbing spin locks all the
time.  this is going to be hell on performance.  without thinking very
hard about the problem, i think that spin lock could be made a QLock,
if such a concept exists in windows.  also, there should be a sleep
of 25ms or so to keep the sweeper thread from chewing cpu for no
reason.  AoERequest would then need to send its own requests or
kick Thread into action.  i would think this will have a big effect on
windows performance when a device is down, since it is effectively
running this in a tight loop:

	for(;;){
		KeAcquireSpinLock(&SpinLock, &Irql);
		KeQuerySystemTime(&CurrentTime);
		KeReleaseSpinLock(&SpinLock, Irql);
	}

it's pretty impressive that windows withstands this abuse at all.

another quirk i see is the way the outstanding requests are managed
doesn't appear to square with the standard.  this driver starts
declaring Tags failed if the number of outstanding requests is
>64.  (again in Thread.)  the number of outstanding tags needs to
be bounded by the maximum frames the aoe device allows and
if the driver itself has hit its limit, the io should sleep until there
is room in the queue.

- erik