On Tue, Jun 13, 2017 at 11:09 PM, Juergen Gross wrote:
> On 14/06/17 06:56, Andy Lutomirski wrote:
>> x86's lazy TLB mode used to be fairly weak -- it would switch to
>> init_mm the first time it tried to flush a lazy TLB. This meant an
>> unnecessary CR3 write and, if the flush was remote, an un
On Sun, Jun 18, 2017 at 1:06 AM, Nadav Amit wrote:
>
>> On Jun 13, 2017, at 9:56 PM, Andy Lutomirski wrote:
>>
>> x86's lazy TLB mode used to be fairly weak -- it would switch to
>> init_mm the first time it tried to flush a lazy TLB. This meant an
>> unnecessary CR3 write and, if the flush was
> On Jun 13, 2017, at 9:56 PM, Andy Lutomirski wrote:
>
> x86's lazy TLB mode used to be fairly weak -- it would switch to
> init_mm the first time it tried to flush a lazy TLB. This meant an
> unnecessary CR3 write and, if the flush was remote, an unnecessary
> IPI.
>
> Rewrite it entirely.
On Wed, Jun 14, 2017 at 3:33 PM, Dave Hansen wrote:
> On 06/13/2017 09:56 PM, Andy Lutomirski wrote:
>> - if (cpumask_test_cpu(cpu, &batch->cpumask))
>> + if (cpumask_test_cpu(cpu, &batch->cpumask)) {
>> + local_irq_disable();
>> flush_tlb_func_local(&info, TLB_LO
On 06/13/2017 09:56 PM, Andy Lutomirski wrote:
> - if (cpumask_test_cpu(cpu, &batch->cpumask))
> + if (cpumask_test_cpu(cpu, &batch->cpumask)) {
> + local_irq_disable();
> flush_tlb_func_local(&info, TLB_LOCAL_SHOOTDOWN);
> + local_irq_enable();
> +
On 14/06/17 06:56, Andy Lutomirski wrote:
> x86's lazy TLB mode used to be fairly weak -- it would switch to
> init_mm the first time it tried to flush a lazy TLB. This meant an
> unnecessary CR3 write and, if the flush was remote, an unnecessary
> IPI.
>
> Rewrite it entirely. When we enter laz
x86's lazy TLB mode used to be fairly weak -- it would switch to
init_mm the first time it tried to flush a lazy TLB. This meant an
unnecessary CR3 write and, if the flush was remote, an unnecessary
IPI.
Rewrite it entirely. When we enter lazy mode, we simply remove the
cpu from mm_cpumask. Thi
7 matches
Mail list logo