Thread (54 messages) 54 messages, 5 authors, 2016-07-12

Re: [PATCH 02/13] irq: Introduce IRQD_AFFINITY_MANAGED flag

From: Bart Van Assche <hidden>
Date: 2016-06-16 15:39:27
Also in: linux-nvme, linux-pci, lkml

On 06/16/2016 05:20 PM, Christoph Hellwig wrote:
On Wed, Jun 15, 2016 at 09:36:54PM +0200, Bart Van Assche wrote:
quoted
Do you agree that - ignoring other interrupt assignments - that the latter
interrupt assignment scheme would result in higher throughput and lower
interrupt processing latency?
Probably.  Once we've got it in the core IRQ code we can tweak the
algorithm to be optimal.
Sorry but I'm afraid that we are embedding policy in the kernel, 
something we should not do. I know that there are workloads for which 
dedicating some CPU cores to interrupt processing and other CPU cores to 
running kernel threads improves throughput, probably because this 
results in less cache eviction on the CPU cores that run kernel threads 
and some degree of interrupt coalescing on the CPU cores that process 
interrupts. My concern is that I doubt that there is an interrupt 
assignment scheme that works optimally for all workloads. Hence my 
request to preserve the ability to modify interrupt affinity from user 
space.

Bart.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help