Date: Sun, 29 Oct 2017 10:24:07 -0600 From: Ian Lepore <ian@freebsd.org> To: Matt Joras <mjoras@FreeBSD.org>, "freebsd-arch@FreeBSD.org" <freebsd-arch@FreeBSD.org> Subject: Re: Allow faster eventhandler dispatching by keeping pointers to handler lists. Message-ID: <1509294247.21609.12.camel@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1509294247.21609.12.camel>