cvs commit: src/sys/kern kern_poll.c

[Luigi Rizzo]

On Mon, Sep 05, 2005 at 10:00:50PM +0400, Gleb Smirnoff wrote:
> On Mon, Sep 05, 2005 at 09:43:41AM -0700, Luigi Rizzo wrote:
> L> gleb, could you document how you are using the PRF_RUNNING
> L> and PRF_LEAVING flags that you added ?
> 
> Ok, I will. Tomorrow or today.
> 
> L> also i am unclear on whether there is a race condition involving
> L> unregistering poll (second part of netisr_poll())
...
> Yes, the race is possible and known to me, though I haven't
> triggered it. To fix it the plan is to turn polling off/on
> functionally, not on the next tick or on next interrupt.
> This idea has already been implemented in DragonFlyBSD.
> 
> Since the race is not runtime one, and requires idle_poll to be
> enabled, which is not default setting, we can live with it.

as long as known issues are mentioned, i am fine with it.
but please do add comments in the code to mention them, because
it is (to me at least) very hard sometimes to figure out
races etc and it saves a lot of time to read these notes.

> With current design really we get a very small parallelizm in three
> threads: netisr, idlepoll, trap. This was not the main aim.

idlepoll is one per cpu if i am not wrong. similarly for trap.
In my view, at least the initial design should aim at having only
one polling thread at any time. I.e. at least for poll-in-trap,
if it finds the poll_mtx busy just give up, someone is already working on it;
not sure yet on how to arbitrate idlepoll threads

	cheers
	luigi