Messages in this thread |  | | Subject | Re: [RFC PATCH 1/5] x86: introduce preemption disable prefix | From | Andy Lutomirski <> | Date | Thu, 18 Oct 2018 10:00:37 -0700 |
| |
> On Oct 18, 2018, at 9:47 AM, Nadav Amit <namit@vmware.com> wrote: > > at 8:51 PM, Andy Lutomirski <luto@amacapital.net> wrote: > >>> On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit <namit@vmware.com> wrote: >>> at 6:22 PM, Andy Lutomirski <luto@amacapital.net> wrote: >>> >>>>> On Oct 17, 2018, at 5:54 PM, Nadav Amit <namit@vmware.com> wrote: >>>>> >>>>> It is sometimes beneficial to prevent preemption for very few >>>>> instructions, or prevent preemption for some instructions that precede >>>>> a branch (this latter case will be introduced in the next patches). >>>>> >>>>> To provide such functionality on x86-64, we use an empty REX-prefix >>>>> (opcode 0x40) as an indication that preemption is disabled for the >>>>> following instruction. >>>> >>>> Nifty! >>>> >>>> That being said, I think you have a few bugs. First, you can’t just ignore >>>> a rescheduling interrupt, as you introduce unbounded latency when this >>>> happens — you’re effectively emulating preempt_enable_no_resched(), which >>>> is not a drop-in replacement for preempt_enable(). To fix this, you may >>>> need to jump to a slow-path trampoline that calls schedule() at the end or >>>> consider rewinding one instruction instead. Or use TF, which is only a >>>> little bit terrifying… >>> >>> Yes, I didn’t pay enough attention here. For my use-case, I think that the >>> easiest solution would be to make synchronize_sched() ignore preemptions >>> that happen while the prefix is detected. It would slightly change the >>> meaning of the prefix. > > So thinking about it further, rewinding the instruction seems the easiest > and most robust solution. I’ll do it. > >>>> You also aren’t accounting for the case where you get an exception that >>>> is, in turn, preempted. >>> >>> Hmm.. Can you give me an example for such an exception in my use-case? I >>> cannot think of an exception that might be preempted (assuming #BP, #MC >>> cannot be preempted). >> >> Look for cond_local_irq_enable(). > > I looked at it. Yet, I still don’t see how exceptions might happen in my > use-case, but having said that - this can be fixed too.
I’m not totally certain there’s a case that matters. But it’s worth checking
> > To be frank, I paid relatively little attention to this subject. Any > feedback about the other parts and especially on the high-level approach? Is > modifying the retpolines in the proposed manner (assembly macros) > acceptable? >
It’s certainly a neat idea, and it could be a real speedup.
> Thanks, > Nadav
|  |