From owner-freebsd-current@FreeBSD.ORG  Thu Jan 23 00:37:15 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id BD2D54EE;
 Thu, 23 Jan 2014 00:37:15 +0000 (UTC)
Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238])
 by mx1.freebsd.org (Postfix) with ESMTP id 7C9E1161B;
 Thu, 23 Jan 2014 00:37:15 +0000 (UTC)
Received: by onelab2.iet.unipi.it (Postfix, from userid 275)
 id 25AE07300A; Thu, 23 Jan 2014 01:39:48 +0100 (CET)
Date: Thu, 23 Jan 2014 01:39:48 +0100
From: Luigi Rizzo <rizzo@iet.unipi.it>
To: John Baldwin <jhb@freebsd.org>
Subject: Re: possible selrecord optimization ?
Message-ID: <20140123003948.GC292@onelab2.iet.unipi.it>
References: <CA+hQ2+hW4_8tkCqyUWUWR_VV+6Jp=t0XzVE5kaWFz=SKDd2bow@mail.gmail.com>
 <201401221429.56745.jhb@freebsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201401221429.56745.jhb@freebsd.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: freebsd-current@freebsd.org, FreeBSD Current <current@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
 <freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 00:37:15 -0000

On Wed, Jan 22, 2014 at 02:29:56PM -0500, John Baldwin wrote:
> On Tuesday, January 21, 2014 9:25:27 pm Luigi Rizzo wrote:
> > Looking at how selrecord() / selwakeup() and their Linux counterparts
> > poll_wait() and wake_up() are used, i noticed the following:
....
> > I wonder if we could use the same optimization as Linux:
> > as soon as pollscan/selscan detects a non-blocking fd,
> > make selrecord a no-op (which is probably as simple
> > as setting SELTD_RESCAN; and since it only goes up
> > we do not need to lock to check it).
> 
> Yes, I think this would work fine.  I think setting SELTD_RESCAN as a way to 
> do it is fine as well.

excellent, thanks.

I also have two related questions:

1. why isn't the struct mtx part of the struct selinfo instead
   of being grabbed from the mtxpool_select ?

2. am i correct that we do need to protect concurrent invocations
   of selrecord() on the same selinfo because mtx_pool_find()
   return the same mutex for a given struct selinfo ?

In case, any objections if i add some comments to the code
to explain the above ?

cheers
luigi