On Thu, Feb 20, 2020 at 11:37:32AM +0100, Dmitry Vyukov wrote: > On Wed, Feb 19, 2020 at 6:20 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > > On Wed, Feb 19, 2020 at 05:30:25PM +0100, Peter Zijlstra wrote: > > > > > By inlining everything in poke_int3_handler() (except bsearch :/) we can > > > mark the whole function off limits to everything and call it a day. That > > > simplicity has been the guiding principle so far. > > > > > > Alternatively we can provide an __always_inline variant of bsearch(). > > > > This reduces the __no_sanitize usage to just the exception entry > > (do_int3) and the critical function: poke_int3_handler(). > > > > Is this more acceptible? > > Let's say it's more acceptable. > > Acked-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx> Thanks, I'll go make it happen. > I guess there is no ideal solution here. > > Just a straw man proposal: expected number of elements is large enough > to make bsearch profitable, right? I see 1 is a common case, but the > other case has multiple entries. Latency was the consideration; the linear search would dramatically increase the runtime of the exception. The current limit is 256 entries and we're hitting that quite often. (we can trivially increase, but nobody has been able to show significant benefits for that -- as of yet)
