From owner-freebsd-arch@freebsd.org Sun Oct 29 16:24:15 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E446E4600B for ; Sun, 29 Oct 2017 16:24:15 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39599839EA for ; Sun, 29 Oct 2017 16:24:14 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 992f7e04-bcc5-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 992f7e04-bcc5-11e7-a893-25625093991c; Sun, 29 Oct 2017 16:24:13 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9TGO7km001408; Sun, 29 Oct 2017 10:24:07 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1509294247.21609.12.camel@freebsd.org> Subject: Re: Allow faster eventhandler dispatching by keeping pointers to handler lists. From: Ian Lepore To: Matt Joras , "freebsd-arch@FreeBSD.org" Date: Sun, 29 Oct 2017 10:24:07 -0600 In-Reply-To: <1509293552.21609.5.camel@freebsd.org> References: <1509243567.56824.103.camel@freebsd.org> <3a71dd31-99cb-c891-9d52-a7f2e7010011@FreeBSD.org> <1509293552.21609.5.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 16:24:15 -0000 On Sun, 2017-10-29 at 10:12 -0600, Ian Lepore wrote: > On Sat, 2017-10-28 at 19:37 -0700, Matt Joras wrote: > > > > On 10/28/2017 19:19, Ian Lepore wrote: > > > > > > > > > There has been some talk lately of the kernel eventhandler > > > mechanism > > > being inefficient due to holding a lock while walking a global list > > > doing strcmp() to find the right list of handlers.  I've posted a > > > phabricator review to alleviate that by allowing high-frequency > > > events > > > to pre-define the event list and keep a pointer to it, to avoid the > > > name lookups. > > > > > > https://reviews.freebsd.org/D12821 > > > > > > -- Ian > > >   > > Hah, as it happens I just posted a revision with largely the same > > intention, though I approached the problem a bit differently: > > https://reviews.freebsd.org/D12814. > > > > Matt > > Actually, it looks like we've done nearly identical work, modulo some > minor naming differences (that I'm completely agnostic about), and you > have the EHL_NONEMPTY flag that didn't occur to me until after I > created the phab review last night. > > The other big difference is that mine still links the fast/static lists > into the global list-of-lists, to preserve what I call "late loose > binding" where an event handler can register for events before the > event provider is present (picture a module that monitors events which > gets loaded before a module that produces those events). > > It ocurred to me this morning that an optimization for mine would be to > place any list created by eventhandler_create_list() at the end of the > global list, on the theory that it will mostly be accessed directly via > pointer and the items at the head of the global list should be the ones > more likely to be searched by name. > > -- Ian Oops, I apparently overlooked _eventhandler_insert_static() in your changes.  I think if that were changed to first check whether the new handler list already exists on the global list, our changes really would be essentially identical. -- Ian