From owner-freebsd-current@FreeBSD.ORG Thu Jan 23 20:34:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CE2C2D7; Thu, 23 Jan 2014 20:34:42 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2490217F8; Thu, 23 Jan 2014 20:34:42 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1C355B948; Thu, 23 Jan 2014 15:34:41 -0500 (EST) From: John Baldwin To: Luigi Rizzo Subject: Re: possible selrecord optimization ? Date: Thu, 23 Jan 2014 14:52:41 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201401221429.56745.jhb@freebsd.org> <20140123003948.GC292@onelab2.iet.unipi.it> In-Reply-To: <20140123003948.GC292@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401231452.41509.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 23 Jan 2014 15:34:41 -0500 (EST) Cc: freebsd-current@freebsd.org, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 20:34:42 -0000 On Wednesday, January 22, 2014 7:39:48 pm Luigi Rizzo wrote: > 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 ? I think this is because there is no selinfo_init() and no selinfo_destroy(), so there is no way to manage the lifetime of the mutex were it embedded into the structure. Also, if there are a lot of these structures, but only a subset of them are ever accessed, then a smaller set of locks that are hashed onto the structures may work just fine without introducing extra contention (but with the benefit of saving space in the structures). > 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 ? If you mean 'do not need', yes. mtx_pool_find() does a hash on the address, so it will always return the same lock for a given selinfo, and no external locking should be needed by callers. However, callers often need to check other state for which they need to hold a lock anyway. OTOH, if, for example, socket buffer locks were reader/writer locks, sopoll_generic() could use read locks on the socket buffers even while calling selrecord(). > In case, any objections if i add some comments to the code > to explain the above ? Not from me. :) -- John Baldwin