9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: erik quanstrom <quanstro@quanstro.net>
To: mattmobile@proweb.co.uk, 9fans@9fans.net
Subject: [9fans] offtopic: winaoe
Date: Mon, 14 Jul 2008 10:24:31 -0400	[thread overview]
Message-ID: <4af4fdc2ab262bb8487646699ef24bae@quanstro.net> (raw)
In-Reply-To: <487A7FB0.7080009@proweb.co.uk>

> 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




      reply	other threads:[~2008-07-14 14:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bcf6455ae643bb5cb35cb1b7877e2401@quanstro.net>
2008-07-13 20:13 ` [9fans] Anatomy of a vblade image matt
2008-07-13 20:54   ` erik quanstrom
2008-07-13 22:20     ` matt
2008-07-14 14:24       ` erik quanstrom [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4af4fdc2ab262bb8487646699ef24bae@quanstro.net \
    --to=quanstro@quanstro.net \
    --cc=9fans@9fans.net \
    --cc=mattmobile@proweb.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).