From: Ethan Zhao <haifeng.zhao@linux.intel.com>
To: Peng Zhang <zhangpeng.00@bytedance.com>,
joro@8bytes.org, will@kernel.org
Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
robin.murphy@arm.com
Subject: Re: [External] Re: [PATCH v2] iommu/iova: Optimize alloc_iova with rbtree_augmented
Date: Fri, 26 Aug 2022 16:58:48 +0800 [thread overview]
Message-ID: <a2479500-479a-22ef-3bd2-90606a26a35e@linux.intel.com> (raw)
In-Reply-To: <486fcde8-e9f5-e40c-db5d-fd3ade59b267@bytedance.com>
Peng,
在 2022/8/25 16:10, Peng Zhang 写道:
>
> Hi,
>
> Here is a real example. The version of kernel is 5.4.56.
> Occurs when a lot of iova are not released for a long time.
>
> [Wed May 25 05:27:59 2022] watchdog: BUG: soft lockup - CPU#58 stuck
> for 23s! [ksoftirqd/58:302]
> [Wed May 25 05:27:59 2022] Call Trace:
> [Wed May 25 05:27:59 2022] alloc_iova+0xf2/0x140
> [Wed May 25 05:27:59 2022] alloc_iova_fast+0x56/0x251
The rcache doesn't work at all , the worst case.
> [Wed May 25 05:27:59 2022] dma_ops_alloc_iova.isra.27+0x4b/0x70
> [Wed May 25 05:27:59 2022] __map_single.isra.28+0x4a/0x1d0
> [Wed May 25 05:27:59 2022] mlx5e_sq_xmit+0x98d/0x12b0 [mlx5_core]
> [Wed May 25 05:27:59 2022] ? packet_rcv+0x43/0x460
> [Wed May 25 05:27:59 2022] ? dev_hard_start_xmit+0x90/0x1e0
> [Wed May 25 05:27:59 2022] ? sch_direct_xmit+0x111/0x320
> [Wed May 25 05:27:59 2022] ? __qdisc_run+0x143/0x540
> [Wed May 25 05:27:59 2022] ? __dev_queue_xmit+0x6c3/0x8e0
> [Wed May 25 05:27:59 2022] ? ip_finish_output2+0x2d5/0x580
> [Wed May 25 05:27:59 2022] ? __ip_finish_output+0xe9/0x1b0
> [Wed May 25 05:27:59 2022] ? ip_output+0x6c/0xe0
> [Wed May 25 05:27:59 2022] ? __ip_finish_output+0x1b0/0x1b0
> [Wed May 25 05:27:59 2022] ? __ip_queue_xmit+0x15d/0x420
> [Wed May 25 05:27:59 2022] ? __tcp_transmit_skb+0x405/0x600
> [Wed May 25 05:27:59 2022] ? tcp_delack_timer_handler+0xb7/0x1b0
> [Wed May 25 05:27:59 2022] ? tcp_delack_timer+0x8b/0xa0
> [Wed May 25 05:27:59 2022] ? tcp_delack_timer_handler+0x1b0/0x1b0
> [Wed May 25 05:27:59 2022] ? call_timer_fn+0x2b/0x120
> [Wed May 25 05:27:59 2022] ? run_timer_softirq+0x1a6/0x420
> [Wed May 25 05:27:59 2022] ? update_load_avg+0x7e/0x640
> [Wed May 25 05:27:59 2022] ? update_curr+0xe1/0x1d0
> [Wed May 25 05:27:59 2022] ? __switch_to+0x7a/0x3e0
> [Wed May 25 05:27:59 2022] ? __do_softirq+0xda/0x2da
> [Wed May 25 05:27:59 2022] ? sort_range+0x20/0x20
> [Wed May 25 05:27:59 2022] ? run_ksoftirqd+0x26/0x40
> [Wed May 25 05:27:59 2022] ? smpboot_thread_fn+0xb8/0x150
> [Wed May 25 05:27:59 2022] ? kthread+0x110/0x130
> [Wed May 25 05:27:59 2022] ? kthread_park+0x80/0x80
> [Wed May 25 05:27:59 2022] ? ret_from_fork+0x1f/0x30
>
> I did some more tests.
>
> The test is single threaded.
> Granule is 4k, limit is 2^20.
>
> When the 1/4 address space is occupied by iova,
> Repeat the following two steps：
>
> 1. Randomly releases an iova.
> 2. Allocate an iova of size 1 within the allocation limit of 2^20.
>
> Before improvement:
>> Tracing 1 functions for "alloc_iova"... Hit Ctrl-C to end.
>> ^C
>> nsecs : count distribution
>> 0 -> 1 : 0 | |
>> 2 -> 3 : 0 | |
>> 4 -> 7 : 0 | |
>> 8 -> 15 : 0 | |
>> 16 -> 31 : 0 | |
>> 32 -> 63 : 0 | |
>> 64 -> 127 : 0 | |
>> 128 -> 255 : 0 | |
>> 256 -> 511 : 352
>> | |
>> 512 -> 1023 : 258078
>> |****************************************|
>> 1024 -> 2047 : 3612
>> | |
>> 2048 -> 4095 : 426
>> | |
>> 4096 -> 8191 : 183
>> | |
>> 8192 -> 16383 : 6 | |
>> 16384 -> 32767 : 5 | |
>> 32768 -> 65535 : 9 | |
>> 65536 -> 131071 : 18 | |
>> 131072 -> 262143 : 28 | |
>> 262144 -> 524287 : 74 | |
>> 524288 -> 1048575 : 109
>> | |
>> 1048576 -> 2097151 : 170
>> | |
>> 2097152 -> 4194303 : 100
>> | |
>> 4194304 -> 8388607 : 1 | |
>>
>> avg = 3110 nsecs, total: 818614399 nsecs, count: 263171
>>
>> Tracing 1 functions for "remove_iova"... Hit Ctrl-C to end.
>> ^C
>> nsecs : count distribution
>> 0 -> 1 : 0 | |
>> 2 -> 3 : 0 | |
>> 4 -> 7 : 0 | |
>> 8 -> 15 : 0 | |
>> 16 -> 31 : 0 | |
>> 32 -> 63 : 0 | |
>> 64 -> 127 : 0 | |
>> 128 -> 255 : 0 | |
>> 256 -> 511 : 250651
>> |****************************************|
>> 512 -> 1023 : 12405
>> |* |
>> 1024 -> 2047 : 111
>> | |
>> 2048 -> 4095 : 1 | |
>>
>> avg = 433 nsecs, total: 114136319 nsecs, count: 263168
>
> With improvement:
>> Tracing 1 functions for "alloc_iova"... Hit Ctrl-C to end.
>> ^C
>> nsecs : count distribution
>> 0 -> 1 : 0 | |
>> 2 -> 3 : 0 | |
>> 4 -> 7 : 0 | |
>> 8 -> 15 : 0 | |
>> 16 -> 31 : 0 | |
>> 32 -> 63 : 0 | |
>> 64 -> 127 : 0 | |
>> 128 -> 255 : 0 | |
>> 256 -> 511 : 0 | |
>> 512 -> 1023 : 258975
>> |****************************************|
>> 1024 -> 2047 : 3618
>> | |
>> 2048 -> 4095 : 497
>> | |
>> 4096 -> 8191 : 74 | |
>> 8192 -> 16383 : 4 | |
>> 16384 -> 32767 : 1 | |
>>
>> avg = 637 nsecs, total: 167854061 nsecs, count: 263169
>>
>> Tracing 1 functions for "remove_iova"... Hit Ctrl-C to end.
>> ^C
>> nsecs : count distribution
>> 0 -> 1 : 0 | |
>> 2 -> 3 : 0 | |
>> 4 -> 7 : 0 | |
>> 8 -> 15 : 0 | |
>> 16 -> 31 : 0 | |
>> 32 -> 63 : 0 | |
>> 64 -> 127 : 0 | |
>> 128 -> 255 : 0 | |
>> 256 -> 511 : 221560
>> |****************************************|
>> 512 -> 1023 : 41427
>> |******* |
>> 1024 -> 2047 : 179
>> | |
>> 2048 -> 4095 : 2 | |
>>
>> avg = 477 nsecs, total: 125540399 nsecs, count: 263168
Though only 3-4 drivers use alloc_iova() directly, in my understanding
your test has simulated the worst case, rcache doesn't work at all,
"alloc_iova" +“remove_iova” number looks great for worst case.
Reviewed-by: Ethan Zhao <haifeng.zhao@linux.intel.com>
>
>> s/distbution/distribution ?
> Sorry, it's a typo.
>
> I don't have a test program for "alloc_iova_fast + free_iova_fast"
> right now.
>
> Thanks,
>
> Peng
--
"firm, enduring, strong, and long-lived"
next prev parent reply other threads:[~2022-08-26 8:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-24 9:51 [PATCH v2] iommu/iova: Optimize alloc_iova with rbtree_augmented Peng Zhang
2022-08-24 12:30 ` Ethan Zhao
2022-08-25 8:10 ` [External] " Peng Zhang
2022-08-26 8:58 ` Ethan Zhao [this message]
2022-08-26 10:28 ` Peng Zhang
2022-09-01 10:45 ` John Garry
2022-09-02 3:30 ` Peng Zhang
2022-09-21 1:15 ` wangjie (L)
2022-09-21 3:55 ` Peng Zhang
2022-09-21 10:54 ` wangjie (L)
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=a2479500-479a-22ef-3bd2-90606a26a35e@linux.intel.com \
--to=haifeng.zhao@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
--cc=zhangpeng.00@bytedance.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).