[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070206233907.GW32307@ca-server1.us.oracle.com>
Date: Tue, 6 Feb 2007 15:39:07 -0800
From: Joel Becker <Joel.Becker@...cle.com>
To: Davide Libenzi <davidel@...ilserver.org>
Cc: Kent Overstreet <kent.overstreet@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Zach Brown <zach.brown@...cle.com>,
Ingo Molnar <mingo@...e.hu>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-aio@...ck.org, Suparna Bhattacharya <suparna@...ibm.com>,
Benjamin LaHaise <bcrl@...ck.org>
Subject: Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
On Tue, Feb 06, 2007 at 03:23:47PM -0800, Davide Libenzi wrote:
> struct async_submit {
> void *cookie;
> int sysc_nbr;
> int nargs;
> long args[ASYNC_MAX_ARGS];
> int async_result;
> };
>
> int async_submit(struct async_submit *a, int n);
>
> And async_submit() can mark each one ->async_result with -EASYNC (syscall
> has been batched), or another code (syscall completed w/out schedule).
> IMO, once you get a -EASYNC for a syscall, you *have* to retire the result.
There are pains here, though. On every submit, you have to walk
the entire vector just to know what did or did not complete. I've seen
this in other APIs (eg, async_result would be -EAGAIN for lack of
resources to start this particular fibril). Userspace submit ends up
always walking the array of submissions twice - once to prep them, and
once to check if they actually went async. For longer lists of I/Os,
this is expensive.
Joel
--
"Too much walking shoes worn thin.
Too much trippin' and my soul's worn thin.
Time to catch a ride it leaves today
Her name is what it means.
Too much walking shoes worn thin."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@...cle.com
Phone: (650) 506-8127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists