lkml.org 
[lkml]   [2002]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] async poll for 2.5
Benjamin LaHaise wrote:

>I suppose one way of getting the async poll code up to snuff would be to
>cache the poll registration in the file descriptor. Alternatively, the
>iocb could simply persist until it is cancelled or a refire is permitted
>(so that the event queue does not get overrun).
>
First, can you confirm that your only problem with the async poll code
is the fact that it doesn't amortize the registration/deregistration
cost across multiple events?

I would say that the fact that the async poll code doesn't do this
amortization is not sufficient reason to hold up the patch. A
non-amortizing async poll is sufficiently useful to warrant inclusion.
It is conceivable that some applications will not want to amortize some
of their poll requests. The non-amortizing interface can later be
extended to an amortizing one by defining an "amortize me" bit to the
events request mask.

I don't think caching the registration in the file descriptor is a good
idea--there can be multiple registrations against a given fd. The
registration should be cached close to the iocb--either in the iocb or
in some structure that directly references the iocb.

The model for multiple-events-per-iocb I was thinking of is as follows:

Add a concept of a "partial completion". Unlike a normal completion,
when a partial completion event fires the iocb is not freed. Instead
the iocb goes into a "fired" state.

When an iocb is in the fired state, it will not generate any more
completion events until it is "rearmed" by user space. The method by
which user space rearms an iocb is to be determined. Upon rearming, the
iocb is once again able to generate either a partial or normal
completion. As with submission, rearming can generate this completion
immediately if the situation warrants.

Canceling an iocb in the rearmed state is the same as canceling an iocb
that has never generated a completion event. Canceling an iocb in the
fired state returns a normal completion through the cancellation
interface and returns a distinct error code (not 0 or -EAGAIN) to inform
the caller that there is an outstanding event to be synchronized with.

Attempting to rearm a canceled iocb returns an error, probably -EAGAIN
to be consistent with cancellation.


[unhandled content-type:application/x-pkcs7-signature]
\
 
 \ /
  Last update: 2005-03-22 13:30    [from the cache]
©2003-2011 Jasper Spaans