Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 Oct 2017 10:12:32 -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:  <1509293552.21609.5.camel@freebsd.org>
In-Reply-To: <3a71dd31-99cb-c891-9d52-a7f2e7010011@FreeBSD.org>
References:  <1509243567.56824.103.camel@freebsd.org> <3a71dd31-99cb-c891-9d52-a7f2e7010011@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1509293552.21609.5.camel>