From: Alex Williamson
> Sent: 17 December 2015 21:07
...
> > Is this all related to the statements in the PCI(e) spec that the
> > MSI-X table and Pending bit array should in their own BARs?
> > (ISTR it even suggests a BAR each.)
> >
> > Since the MSI-X table exists in device memory/registers
> The MSI-X table is paravirtualized on vfio in general and interrupt
> remapping theoretically protects against errant interrupts, so why is
> this PPC64 specific? We have the same safeguards on x86 if we want to
> decide they're sufficient. Offhand, the only way I can think that a
> device can
From: Razya Ladelsky
Michael S. Tsirkin m...@redhat.com wrote on 20/08/2014 01:57:10 PM:
Results:
Netperf, 1 vm:
The polling patch improved throughput by ~33% (1516 MB/sec - 2046
MB/sec).
Number of exits/sec decreased 6x.
The same improvement was shown when I tested with 3
From: Alexey Kardashevskiy
...
So IMHO we should either create new, generic iowrite helpers that don't
do any endian swapping at all or do iowrite32(cpu_to_le32(val)) calls.
I'm one of those people for whom iowrite32(le32_to_cpu(val)) makes sense
I do not understand why @val is
From: Alexander Graf
...
+ page = pfn_to_page(pfn);
+ eaddr = (unsigned long)kmap_atomic(page);
+ eaddr |= addr ~PAGE_MASK;
+ *instr = *(u32 *)eaddr;
+ kunmap_atomic((u32 *)eaddr);
I think I'd rather write this as
*instr = *(u32 *)(eaddr | (addr ~PAGE));
From: Alexander Graf
...
+ page = pfn_to_page(pfn);
+ eaddr = (unsigned long)kmap_atomic(page);
+ eaddr |= addr ~PAGE_MASK;
+ *instr = *(u32 *)eaddr;
+ kunmap_atomic((u32 *)eaddr);
I think I'd rather write this as
*instr = *(u32 *)(eaddr | (addr ~PAGE));
Some MPIC implementations tend to generate a spurrious IRQ in the case
of level IRQs going away. IE. they still remember an event occurred and
interrupt the processor, but on IACK return the spurious vector. However
that isn't guaranteed to be the case and it is perfectly ok (and a good
idea)
Some MPIC implementations tend to generate a spurrious IRQ in the case
of level IRQs going away. IE. they still remember an event occurred and
interrupt the processor, but on IACK return the spurious vector. However
that isn't guaranteed to be the case and it is perfectly ok (and a good
idea)
+ n = kmalloc(sizeof *n, GFP_KERNEL | __GFP_NOWARN);
+ if (!n)
+ n = vmalloc(sizeof *n);
I'm slightly confused by this construct.
I thought kmalloc(... GFP_KERNEL) would sleep waiting for
memory (rather than return NULL).
I realise that (for multi-page sizes) that
I think this means that kmalloc() is likely to be faster
(if it doesn't have to sleep), but that vmalloc() is
allocating from a much larger resource.
This make me that that large allocations that are not
temporary should probably be allocated with vmalloc().
vmalloc has some issues
10 matches
Mail list logo
