On Fri, Jan 05, 2007 at 06:36:39PM -0700, Dan Williams ([EMAIL PROTECTED])
wrote:
> >My first impression is that it has too many lists :)
> >
> Ok, I think I can cut this down if I use static allocations for the
> software descriptors.
I did not say, it is bad, it is just first impression :)
I
On Fri, Jan 05, 2007 at 06:36:39PM -0700, Dan Williams ([EMAIL PROTECTED])
wrote:
My first impression is that it has too many lists :)
Ok, I think I can cut this down if I use static allocations for the
software descriptors.
I did not say, it is bad, it is just first impression :)
I can not
[ trimmed the cc to just linux-kernel ]
On 1/3/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
On Tue, Jan 02, 2007 at 02:38:13PM -0700, Dan Williams ([EMAIL PROTECTED])
wrote:
> Would you have time to comment on the approach I have taken to
> implement a standard asynchronous memcpy interface?
[ trimmed the cc to just linux-kernel ]
On 1/3/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Tue, Jan 02, 2007 at 02:38:13PM -0700, Dan Williams ([EMAIL PROTECTED])
wrote:
Would you have time to comment on the approach I have taken to
implement a standard asynchronous memcpy interface? It
generic_write_checks() are done in the submission path, not
repeated during
retries, so such types of checks are not intended to run in the aio
thread.
Ah, I see, I was missing the short-cut which avoids re-running parts
of the write path if we're in a retry.
if
On Tue 2007-01-02 16:18:40, Kent Overstreet wrote:
> >> Any details?
> >
> >Well, one path I tried I couldn't help but post a blog
> >entry about
> >for my friends. I'm not sure it's the direction I'll
> >take with linux-
> >kernel, but the fundamentals are there: the api should
> >be the
>
On Tue 2007-01-02 16:18:40, Kent Overstreet wrote:
Any details?
Well, one path I tried I couldn't help but post a blog
entry about
for my friends. I'm not sure it's the direction I'll
take with linux-
kernel, but the fundamentals are there: the api should
be the
syscall interface,
generic_write_checks() are done in the submission path, not
repeated during
retries, so such types of checks are not intended to run in the aio
thread.
Ah, I see, I was missing the short-cut which avoids re-running parts
of the write path if we're in a retry.
if
On Tue, Jan 02, 2007 at 02:38:13PM -0700, Dan Williams ([EMAIL PROTECTED])
wrote:
> Would you have time to comment on the approach I have taken to
> implement a standard asynchronous memcpy interface? It seems it would
> be a good complement to what you are proposing. The entity that
>
On Tue, Jan 02, 2007 at 02:38:13PM -0700, Dan Williams ([EMAIL PROTECTED])
wrote:
Would you have time to comment on the approach I have taken to
implement a standard asynchronous memcpy interface? It seems it would
be a good complement to what you are proposing. The entity that
describes
On Tue, Jan 02, 2007 at 03:56:09PM -0800, Zach Brown wrote:
> Sorry for the delay, I'm finally back from the holiday break :)
Welcome back !
>
> >(1) The filesystem AIO patchset, attempts to address one part of
> >the problem
> >which is to make regular file IO, (without O_DIRECT)
>
> Any details?
Well, one path I tried I couldn't help but post a blog entry about
for my friends. I'm not sure it's the direction I'll take with linux-
kernel, but the fundamentals are there: the api should be the
syscall interface, and there should be no difference between sync and
async
Sorry for the delay, I'm finally back from the holiday break :)
(1) The filesystem AIO patchset, attempts to address one part of
the problem
which is to make regular file IO, (without O_DIRECT)
asynchronous (mainly
the case of reads of uncached or partially cached files, and
O_SYNC
On 12/28/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
[ I'm only subscribed to linux-fsdevel@ from above Cc list, please keep this
list in Cc: for AIO related stuff. ]
On Wed, Dec 27, 2006 at 04:25:30PM +, Christoph Hellwig ([EMAIL PROTECTED])
wrote:
> (1) note that there is another
On 12/28/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
[ I'm only subscribed to linux-fsdevel@ from above Cc list, please keep this
list in Cc: for AIO related stuff. ]
On Wed, Dec 27, 2006 at 04:25:30PM +, Christoph Hellwig ([EMAIL PROTECTED])
wrote:
(1) note that there is another
Sorry for the delay, I'm finally back from the holiday break :)
(1) The filesystem AIO patchset, attempts to address one part of
the problem
which is to make regular file IO, (without O_DIRECT)
asynchronous (mainly
the case of reads of uncached or partially cached files, and
O_SYNC
Any details?
Well, one path I tried I couldn't help but post a blog entry about
for my friends. I'm not sure it's the direction I'll take with linux-
kernel, but the fundamentals are there: the api should be the
syscall interface, and there should be no difference between sync and
async
On Tue, Jan 02, 2007 at 03:56:09PM -0800, Zach Brown wrote:
Sorry for the delay, I'm finally back from the holiday break :)
Welcome back !
(1) The filesystem AIO patchset, attempts to address one part of
the problem
which is to make regular file IO, (without O_DIRECT)
asynchronous
[ I'm only subscribed to linux-fsdevel@ from above Cc list, please keep this
list in Cc: for AIO related stuff. ]
On Wed, Dec 27, 2006 at 04:25:30PM +, Christoph Hellwig ([EMAIL PROTECTED])
wrote:
> (1) note that there is another problem with the current kevent interface,
> and that is
[ I'm only subscribed to linux-fsdevel@ from above Cc list, please keep this
list in Cc: for AIO related stuff. ]
On Wed, Dec 27, 2006 at 04:25:30PM +, Christoph Hellwig ([EMAIL PROTECTED])
wrote:
(1) note that there is another problem with the current kevent interface,
and that is
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > unified event system for Linux we need people to help out with
> > straightening out these even provides as Evgeny seems to be
> > unwilling/unable to do the work himself and the duplication is
> > simply not acceptable.
>
> yeah.
* Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> The real question here is which interface we want people to use for
> these "combined" applications. Evgeny is heavily pushing kevent for
> this while other seem to prefer integration epoll into the aio
> interface. (1)
>
> I must admit that
On Wed, Dec 27, 2006 at 09:08:56PM +0530, Suparna Bhattacharya wrote:
> (2) Most of these other applications need the ability to process both
> network events (epoll) and disk file AIO in the same loop. With POSIX AIO
> they could at least sort of do this using signals (yeah, and all
>
Here is a quick attempt to summarize where we are heading with a bunch of
AIO patches that I'll be posting over the next few days. Because a few of
these patches have been hanging around for a bit, and have gone through
bursts of iterations from time to time, falling dormant for other phases,
the
Here is a quick attempt to summarize where we are heading with a bunch of
AIO patches that I'll be posting over the next few days. Because a few of
these patches have been hanging around for a bit, and have gone through
bursts of iterations from time to time, falling dormant for other phases,
the
On Wed, Dec 27, 2006 at 09:08:56PM +0530, Suparna Bhattacharya wrote:
(2) Most of these other applications need the ability to process both
network events (epoll) and disk file AIO in the same loop. With POSIX AIO
they could at least sort of do this using signals (yeah, and all
* Christoph Hellwig [EMAIL PROTECTED] wrote:
The real question here is which interface we want people to use for
these combined applications. Evgeny is heavily pushing kevent for
this while other seem to prefer integration epoll into the aio
interface. (1)
I must admit that kevent
* Ingo Molnar [EMAIL PROTECTED] wrote:
unified event system for Linux we need people to help out with
straightening out these even provides as Evgeny seems to be
unwilling/unable to do the work himself and the duplication is
simply not acceptable.
yeah. The internal
28 matches
Mail list logo
