Bug? CPU affinity of iSCSI target doesn't abide by kernel boot args
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx>, <target-devel@xxxxxxxxxxxxxxx>, <linux-scsi@xxxxxxxxxxxxxxx>
- Subject: Bug? CPU affinity of iSCSI target doesn't abide by kernel boot args
- From: Chris Friesen <chris.friesen@xxxxxxxxxxxxx>
- Date: Fri, 9 Mar 2018 15:08:01 -0600
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
I think I've found some suboptimal behaviour in the iSCSI target code, but I'd
like another opinion.
Just as a caveat, this behaviour was first seen on a CentOS 7 kernel, but
looking at the code I think it'll behave the same in master.
Basically, the issue is that the iSCSI target code creates a pair of kernel
threads (one for tx, one for rx) for each connection. Each pair gets affined to
the same logical CPU.
The problem is that this affinity does not reflect kernel boot args such as
"isolcpus", "rcu_nocbs", or "irqaffinity". Instead, it seems to start at cpu0
and increment by one for each pair of kernel threads.
This seems less than ideal. If the sysadmin has tried to ensure certain CPUs
are available for high-performance/low-latency work, it seems odd for the kernel
to arbitrarily stick a pair of I/O threads on them.
Am I missing something? Is there a way to set limits on where these threads are
placed?
Thanks,
Chris
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]
[SCSI Target Devel]
[Linux SCSI Target Infrastructure]
[Kernel Newbies]
[IDE]
[Security]
[Git]
[Netfilter]
[Bugtraq]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Linux ATA RAID]
[Linux IIO]
[Samba]
[Device Mapper]