From: John Garry <john.garry@huawei.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Marc Zyngier <maz@kernel.org>, <bigeasy@linutronix.de>,
chenxiang <chenxiang66@hisilicon.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: About threaded interrupt handler CPU affinity
Date: Tue, 23 Jul 2019 16:29:15 +0100 [thread overview]
Message-ID: <e5cb48fc-081a-f47c-810f-cc649c765ae6@huawei.com> (raw)
In-Reply-To: <8e1201a7-3e69-e048-6aa3-3b87e86d55ac@huawei.com>
>
> Probably because the other CPU(s)
>> in the affinity set are less loaded than the one which handles the hard
>> interrupt.
>
> I will look to get some figures for CPU loading to back this up.
>
As promised, here are some CPU loading figures before and after the
change to make the thread CPU affinity same as the interrupt affinity:
Before:
CPU %usr %sys %irq %soft %idle
all 2.9 13.1 1.2 4.6 78.2
0 0.0 29.3 10.1 58.6 2.0
1 18.2 39.4 0.0 1.0 41.4
2 0.0 2.0 0.0 0.0 98.0
3 16.0 40.0 0.0 0.0 44.0
4 9.7 56.3 0.0 0.0 34.0
5 0.0 0.0 0.0 0.0 100.0
6 0.0 36.0 12.0 45.0 7.0
7 12.5 35.4 0.0 0.0 52.1
8 10.3 38.1 0.0 0.0 51.6
9 0.0 0.0 0.0 0.0 100.0
10 8.2 41.8 0.0 0.0 50.0
11 0.0 0.0 0.0 0.0 100.0
After:
CPU %usr %sys %irq %soft %idle
all 3.5 18.4 2.7 6.8 68.6
0 0.0 20.6 29.9 29.9 19.6
1 0.0 39.8 0.0 50.0 10.2
2 18.6 45.4 0.0 0.0 36.1
3 19.6 48.9 0.0 0.0 31.5
4 0.0 0.0 0.0 0.0 100.0
5 14.9 51.1 0.0 0.0 34.0
6 0.0 20.4 24.5 36.7 18.4
7 0.0 36.0 0.0 63.0 1.0
8 12.2 55.1 0.0 0.0 32.7
9 15.0 57.0 0.0 0.0 28.0
10 13.0 54.0 0.0 0.0 33.0
11 14.6 52.1 0.0 0.0 33.3
The system has 96 cores, and we have 6x CPUs set per interrupt affinity
mask. I'm only showing 2 clusters of 6 CPUs, but the loading pattern is
common across all clusters, albeit higher clusters are generally much
less loaded.
We can see that CPU0,6 are almost 100% loaded before, taking on all the
irq and softirq processing.
With the change, CPU0,6 are much less loaded, and CPU1,7 take on much
softirq processing.
In total, irq and softirq processing has increased - I suppose that the
reason is that we're just pumping through more IO.
We'll do some more testing at lower loads - but from limited testing we
see no regression here. In the above test we're using many disks on the
storage controller (> 20).
Please let me know your thoughts.
Cheers,
John
>>
>> This is heavily use case dependent I assume, so making this a general
>> change is perhaps not a good idea, but we could surely make this
>> optional.
>
> That sounds reasonable. So would the idea be to enable this optionally
> at the request threaded irq call?
>
> Thanks,
> John
>
>>
>> Thanks,
>>
>> tglx
>>
>> .
>>
>
next prev parent reply other threads:[~2019-07-23 15:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-22 14:14 About threaded interrupt handler CPU affinity John Garry
2019-07-22 14:41 ` Marc Zyngier
2019-07-22 15:17 ` John Garry
2019-07-22 15:34 ` Thomas Gleixner
2019-07-22 16:08 ` John Garry
2019-07-23 15:29 ` John Garry [this message]
2019-08-10 9:47 ` Ming Lei
2019-08-12 8:46 ` John Garry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e5cb48fc-081a-f47c-810f-cc649c765ae6@huawei.com \
--to=john.garry@huawei.com \
--cc=bigeasy@linutronix.de \
--cc=chenxiang66@hisilicon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.