search for: shootdowns

On 03/07/2019 18:02, Nadav Amit wrote: >> On Jul 3, 2019, at 7:04 AM, Juergen Gross <jgross at suse.com> wrote: >> >> On 03.07.19 01:51, Nadav Amit wrote: >>> To improve TLB shootdown performance, flush the remote and local TLBs >>> concurrently. Introduce flush_tlb_multi() that does so. Introduce >>> paravirtual versions of flush_tlb_multi() for

> On Jun 25, 2019, at 8:36 PM, Andy Lutomirski <luto at kernel.org> wrote: > > On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit <namit at vmware.com> wrote: >> To improve TLB shootdown performance, flush the remote and local TLBs >> concurrently. Introduce flush_tlb_multi() that does so. The current >> flush_tlb_others() interface is kept, since paravirtual

On 03.07.19 01:51, Nadav Amit wrote: > To improve TLB shootdown performance, flush the remote and local TLBs > concurrently. Introduce flush_tlb_multi() that does so. Introduce > paravirtual versions of flush_tlb_multi() for KVM, Xen and hyper-v (Xen > and hyper-v are only compile-tested). > > While the updated smp infrastructure is capable of running a function on > a single

On 03.07.19 01:51, Nadav Amit wrote: > To improve TLB shootdown performance, flush the remote and local TLBs > concurrently. Introduce flush_tlb_multi() that does so. Introduce > paravirtual versions of flush_tlb_multi() for KVM, Xen and hyper-v (Xen > and hyper-v are only compile-tested). > > While the updated smp infrastructure is capable of running a function on > a single

...l BLKIF_MAX_SEGMENTS_PER_REQUEST segments. 2) Otherwise, we revert to non-persistent grants for all future grefs. In writing this patch, the question arrises as to if the additional cost of performing memcpys in the guest (to/from the pool of granted pages) outweigh the gains of not performing TLB shootdowns. The answer to that question is `no''. There appears to be very little, if any additional cost to the guest of using persistent grants. There is perhaps a small saving, from the reduced number of hypercalls performed in granting, and ending foreign access. Signed-off-by: Oliver Chick <...

On 19 Nov 2013, at 17:58, Kostya Serebryany <kcc at google.com> wrote: > On Tue, Nov 19, 2013 at 9:56 PM, Kuperstein, Michael M <michael.m.kuperstein at intel.com> wrote: >> What I’m trying to say is that according to my understanding of the C++11 memory model, even in that small reproducer, the store to g and the load from g are in fact a data race. >> >> (This

...er interrupts PND: 0 0 0 0 Performance pending work RES: 436674 440302 2195268 1451020 Rescheduling interrupts CAL: 169 265 203 251 Function call interrupts TLB: 43920 44257 50177 52884 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 1073 1073 1073 1073 Machine check p...

On Tue, Nov 19, 2013 at 10:20 PM, David Chisnall < David.Chisnall at cl.cam.ac.uk> wrote: > On 19 Nov 2013, at 17:58, Kostya Serebryany <kcc at google.com> wrote: > > > On Tue, Nov 19, 2013 at 9:56 PM, Kuperstein, Michael M < > michael.m.kuperstein at intel.com> wrote: > >> What I’m trying to say is that according to my understanding of the > C++11

To improve TLB shootdown performance, flush the remote and local TLBs concurrently. Introduce flush_tlb_multi() that does so. The current flush_tlb_others() interface is kept, since paravirtual interfaces need to be adapted first before it can be removed. This is left for future work. In such PV environments, TLB flushes are not performed, at this time, concurrently. Add a static key to tell

To improve TLB shootdown performance, flush the remote and local TLBs concurrently. Introduce flush_tlb_multi() that does so. The current flush_tlb_others() interface is kept, since paravirtual interfaces need to be adapted first before it can be removed. This is left for future work. In such PV environments, TLB flushes are not performed, at this time, concurrently. Add a static key to tell

To improve TLB shootdown performance, flush the remote and local TLBs concurrently. Introduce flush_tlb_multi() that does so. The current flush_tlb_others() interface is kept, since paravirtual interfaces need to be adapted first before it can be removed. This is left for future work. In such PV environments, TLB flushes are not performed, at this time, concurrently. Add a static key to tell

To improve TLB shootdown performance, flush the remote and local TLBs concurrently. Introduce flush_tlb_multi() that does so. The current flush_tlb_others() interface is kept, since paravirtual interfaces need to be adapted first before it can be removed. This is left for future work. In such PV environments, TLB flushes are not performed, at this time, concurrently. Add a static key to tell

----- Original Message ----- > From: "Kostya Serebryany" <kcc at google.com> > To: "David Chisnall" <David.Chisnall at cl.cam.ac.uk> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Tuesday, November 19, 2013 11:01:12 PM > Subject: Re: [LLVMdev] Curiosity about transform changes under Sanitizers (Was: [PATCH]

...b4 219: 64752376 0 PCI-MSI-edge ioc0 NMI: 0 0 Non-maskable interrupts LOC: 993263108 915510467 Local timer interrupts RES: 16326632 9071480 Rescheduling interrupts CAL: 303 529 function call interrupts TLB: 1521462 4810165 TLB shootdowns TRM: 0 0 Thermal event interrupts SPU: 0 0 Spurious interrupts ERR: 0 MIS: 0 Vin?cius Fontes www.asteriskforum.com.br - Informa??es e discuss?o sobre Asterisk e telefonia IP

Josh Poimboeuf <jpoimboe at redhat.com> writes: > - For the most common runtime cases (everything except Xen and vSMP), > vmlinux disassembly now matches what the actual runtime code looks > like. This improves debuggability and kernel developer sanity (a > precious resource). > > ... > > - It's hopefully a first step in simplifying paravirt patching by

On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit <namit at vmware.com> wrote: > > To improve TLB shootdown performance, flush the remote and local TLBs > concurrently. Introduce flush_tlb_multi() that does so. The current > flush_tlb_others() interface is kept, since paravirtual interfaces need > to be adapted first before it can be removed. This is left for future > work. In

I'm looking at adding Xen SMP support, so I'm trying to work out what pv_ops we need, and how to cut into the existing smp stuff. smpboot.c has a mixture of stuff which is generally useful for SMP stuff (the various CPU sets, and presumably the sibling relationships are useful in principle), but also a whole pile of APIC stuff which is irrelevent to Xen. It has these exported

I'm looking at adding Xen SMP support, so I'm trying to work out what pv_ops we need, and how to cut into the existing smp stuff. smpboot.c has a mixture of stuff which is generally useful for SMP stuff (the various CPU sets, and presumably the sibling relationships are useful in principle), but also a whole pile of APIC stuff which is irrelevent to Xen. It has these exported

...219: 2014578 0 PCI-MSI-edge eth3 NMI: 0 0 Non-maskable interrupts LOC: 2180853 1019374 Local timer interrupts RES: 1655 872 Rescheduling interrupts CAL: 49 74 function call interrupts TLB: 5322 5969 TLB shootdowns TRM: 0 0 Thermal event interrupts SPU: 0 0 Spurious interrupts ERR: 0 MIS: 0 lsusb Bus 007 Device 003: ID e4e4:1152 Bus 007 Device 002: ID e4e4:1142 Bus 007 Device 001: ID 0000:0000 Bus 005 Device 001: ID 0000:0000 Bus 006 Device...

To improve TLB shootdown performance, flush the remote and local TLBs concurrently. Introduce flush_tlb_multi() that does so. The current flush_tlb_others() interface is kept, since paravirtual interfaces need to be adapted first before it can be removed. This is left for future work. In such PV environments, TLB flushes are not performed, at this time, concurrently. Add a static key to tell