On 12/23/2014 01:14 AM, Ingo Molnar wrote:
>> > {
>> > - mpx_notify_unmap(mm, vma, start, end);
>> > + /*
>> > + * mpx_notify_unmap() goes and reads a rarely-hot
>> > + * cacheline in the mm_struct. That can be expensive
>> > + * enough to be seen in profiles.
>> > + *
>> > + * The mpx_notify_unmap() call and its contents have been
>> > + * observed to affect munmap() performance on hardware
>> > + * where MPX is not present.
>> > + *
>> > + * The unlikely() optimizes for the fast case: no MPX
>> > + * in the CPU, or no MPX use in the process. Even if
>> > + * we get this wrong (in the unlikely event that MPX
>> > + * is widely enabled on some system) the overhead of
>> > + * MPX itself (reading bounds tables) is expected to
>> > + * overwhelm the overhead of getting this unlikely()
>> > + * consistently wrong.
>> > + */
>> > + if (unlikely(cpu_feature_enabled(X86_FEATURE_MPX)))
>> > + mpx_notify_unmap(mm, vma, start, end);
>> > }
> Hm, so this patch still does not help people who have an MPX
> capable CPU but don't have (or don't have many) MPX using apps.
> What about them?
Sorry for the delayed resposne.
The performance regression, as far as I could tell, was the result of a
consistent branch misprediction near the read of mm->bd_addr. I believe
the CPU was able to better predict cpu_feature_enabled() than the
contents of mm->bd_addr.
In running this on a CPU which actually contains MPX, I wasn't able to
see the same regression. The same branch was getting predicted correctly.
I also have a patch to add a global, boot-time MPX disable. It will
clear out the X86_FEATURE_MPX at __setup time. While not optimal, this
would at least let someone who did not have any MPX apps avoid any
potential issues. I was planning on submitting that patch for 3.20.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
