> On Oct 18, 2018, at 9:47 AM, Nadav Amit <[email protected]> wrote:
>
> at 8:51 PM, Andy Lutomirski <[email protected]> wrote:
>
>>> On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit <[email protected]> wrote:
>>> at 6:22 PM, Andy Lutomirski <[email protected]> wrote:
>>>
>>>>> On Oct 17, 2018, at 5:54 PM, Nadav Amit <[email protected]> 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
