From owner-cvs-all@FreeBSD.ORG Mon Sep 5 21:14:52 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D76816A41F; Mon, 5 Sep 2005 21:14:52 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C126743D46; Mon, 5 Sep 2005 21:14:51 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j85LEp3C027484; Mon, 5 Sep 2005 14:14:51 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j85LEpCC027483; Mon, 5 Sep 2005 14:14:51 -0700 (PDT) (envelope-from rizzo) Date: Mon, 5 Sep 2005 14:14:51 -0700 From: Luigi Rizzo To: Gleb Smirnoff Message-ID: <20050905141451.A27290@xorpc.icir.org> References: <200509051602.j85G2Bpo090258@repoman.freebsd.org> <20050905094341.A23343@xorpc.icir.org> <20050905180050.GB41863@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050905180050.GB41863@cell.sick.ru>; from glebius@FreeBSD.org on Mon, Sep 05, 2005 at 10:00:50PM +0400 Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_poll.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2005 21:14:52 -0000 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