Date: Thu, 23 Jan 2014 01:39:48 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current@freebsd.org, FreeBSD Current <current@freebsd.org> Subject: Re: possible selrecord optimization ? Message-ID: <20140123003948.GC292@onelab2.iet.unipi.it> In-Reply-To: <201401221429.56745.jhb@freebsd.org> References: <CA%2BhQ2%2BhW4_8tkCqyUWUWR_VV%2B6Jp=t0XzVE5kaWFz=SKDd2bow@mail.gmail.com> <201401221429.56745.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140123003948.GC292>