cvs commit: src/sys/kern kern_poll.c

[Gleb Smirnoff]

  Luigi,

On Mon, Sep 05, 2005 at 02:14:51PM -0700, Luigi Rizzo wrote:
L> On Mon, Sep 05, 2005 at 10:00:50PM +0400, Gleb Smirnoff wrote:
L> > On Mon, Sep 05, 2005 at 09:43:41AM -0700, Luigi Rizzo wrote:
L> > L> gleb, could you document how you are using the PRF_RUNNING
L> > L> and PRF_LEAVING flags that you added ?
L> > 
L> > Ok, I will. Tomorrow or today.
L> > 
L> > L> also i am unclear on whether there is a race condition involving
L> > L> unregistering poll (second part of netisr_poll())
L> ...
L> > Yes, the race is possible and known to me, though I haven't
L> > triggered it. To fix it the plan is to turn polling off/on
L> > functionally, not on the next tick or on next interrupt.
L> > This idea has already been implemented in DragonFlyBSD.
L> > 
L> > Since the race is not runtime one, and requires idle_poll to be
L> > enabled, which is not default setting, we can live with it.
L> 
L> as long as known issues are mentioned, i am fine with it.
L> but please do add comments in the code to mention them, because
L> it is (to me at least) very hard sometimes to figure out
L> races etc and it saves a lot of time to read these notes.
L> 
L> > With current design really we get a very small parallelizm in three
L> > threads: netisr, idlepoll, trap. This was not the main aim.
L> 
L> idlepoll is one per cpu if i am not wrong. similarly for trap.
L> In my view, at least the initial design should aim at having only
L> one polling thread at any time. I.e. at least for poll-in-trap,
L> if it finds the poll_mtx busy just give up, someone is already working on it;
L> not sure yet on how to arbitrate idlepoll threads

The idlepoll thread is single. The idea about trylocking the poll_mtx
looks good to me, I'll do it after discussing with ru, rwatson, pjd, ...

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE