| Message ID | 20220408073916.1428590-1-yukuai3@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | improve tag allocation under heavy load | expand |
For this one, and other patches you send, they send up in spam because the sender can't be verified. I would encourage you to figure out what is going wrong here, because a lot of your patches end up getting dropped or missed because of it.
在 2022/04/09 3:10, Jens Axboe 写道: > For this one, and other patches you send, they send up in spam because > the sender can't be verified. I would encourage you to figure out what > is going wrong here, because a lot of your patches end up getting > dropped or missed because of it. > Hi, Thanks for your notice, however, I have no clue what is going on right now. I'll look for some help and hopefully that can be fixed. Thanks, Kuai
On 4/8/22 8:26 PM, yukuai (C) wrote: > 在 2022/04/09 3:10, Jens Axboe 写道: >> For this one, and other patches you send, they send up in spam because >> the sender can't be verified. I would encourage you to figure out what >> is going wrong here, because a lot of your patches end up getting >> dropped or missed because of it. >> > > Hi, > > Thanks for your notice, however, I have no clue what is going on right > now. I'll look for some help and hopefully that can be fixed. The easiest is probably to try and send patches to a gmail account. If you don't have one, just create one. That will help you see the issue and verify whatever the fix might be. It might be a company email server issue, hower.
在 2022/04/09 10:28, Jens Axboe 写道: > On 4/8/22 8:26 PM, yukuai (C) wrote: >> 在 2022/04/09 3:10, Jens Axboe 写道: >>> For this one, and other patches you send, they send up in spam because >>> the sender can't be verified. I would encourage you to figure out what >>> is going wrong here, because a lot of your patches end up getting >>> dropped or missed because of it. >>> >> >> Hi, >> >> Thanks for your notice, however, I have no clue what is going on right >> now. I'll look for some help and hopefully that can be fixed. > > The easiest is probably to try and send patches to a gmail account. If > you don't have one, just create one. That will help you see the issue > and verify whatever the fix might be. It might be a company email > server issue, hower. > Thanks very much for your advice, I'll try that asap.
在 2022/04/09 10:28, Jens Axboe 写道: > On 4/8/22 8:26 PM, yukuai (C) wrote: >> 在 2022/04/09 3:10, Jens Axboe 写道: >>> For this one, and other patches you send, they send up in spam because >>> the sender can't be verified. I would encourage you to figure out what >>> is going wrong here, because a lot of your patches end up getting >>> dropped or missed because of it. >>> >> >> Hi, >> >> Thanks for your notice, however, I have no clue what is going on right >> now. I'll look for some help and hopefully that can be fixed. > > The easiest is probably to try and send patches to a gmail account. If > you don't have one, just create one. That will help you see the issue > and verify whatever the fix might be. It might be a company email > server issue, hower. > I tried to send a patch to gmail, however, no issues are found. I am contacting our IT support and hope they can figure out what is going on. By the way, I didn't see anything unusual for my patches in linux-block patchwork: https://patchwork.kernel.org/project/linux-block/list/?series=&submitter=187999&state=&q=&archive=both&delegate= Is there a seperate place to track patches? Thanks, Kuai
On 4/8/22 19:28, Jens Axboe wrote: > The easiest is probably to try and send patches to a gmail account. If > you don't have one, just create one. That will help you see the issue > and verify whatever the fix might be. It might be a company email > server issue, hower. Hi Jens and Yu, I think it's a company email issue. Many servers that receive email rely on the SPF, DKIM & DMARC standards to determine whether or not to classify email as spam. I had to add the following rule to my inbox receive Huawei.com emails: Matches: from:(huawei.com) Do this: Never send it to Spam Thanks, Bart.
Changes in v2: - use a new title - add patches to fix waitqueues' unfairness - path 1-3 - delete patch to add queue flag - delete patch to split big io thoroughly There is a defect for blk-mq compare to blk-sq, specifically split io will end up discontinuous if the device is under high io pressure, while split io will still be continuous in sq, this is because: 1) new io can preempt tag even if there are lots of threads waiting. 2) split bio is issued one by one, if one bio can't get tag, it will go to wail. 3) each time 8(or wake batch) requests is done, 8 waiters will be woken up. Thus if a thread is woken up, it will unlikey to get multiple tags. The problem was first found by upgrading kernel from v3.10 to v4.18, test device is HDD with 256 'max_sectors_kb', and test case is issuing 1m ios with high concurrency. Noted that there is a precondition for such performance problem: There is a certain gap between bandwith for single io with bs=max_sectors_kb and disk upper limit. During the test, I found that waitqueues can be extremly unbalanced on heavy load. This is because 'wake_index' is not set properly in __sbq_wake_up(), see details in patch 3. In this patchset: - patch 1-3 fix waitqueues' unfairness. - patch 4,5 disable tag preemption on heavy load. - patch 6 forces tag preemption for split bios. - patch 7,8 improve large random io for HDD. As I mentioned above, we do meet the problem and I'm trying to fix it at very low cost. However, if anyone still thinks this is not a common case and not worth to optimize, I'll drop them. Test environment: arm64, 96 core with 200 BogoMIPS, test device is HDD. The default 'max_sectors_kb' is 1280(Sorry that I was unable to test on the machine where 'max_sectors_kb' is 256). The single io performance(randwrite): | bs | 128k | 256k | 512k | 1m | 1280k | 2m | 4m | | -------- | ---- | ---- | ---- | ---- | ----- | ---- | ---- | | bw MiB/s | 20.1 | 33.4 | 51.8 | 67.1 | 74.7 | 82.9 | 82.9 | It can be seen that 1280k io is already close to upper limit, and it'll be hard to see differences with the default value, thus I set 'max_sectors_kb' to 128 in the following test. Test cmd: fio \ -filename=/dev/$dev \ -name=test \ -ioengine=psync \ -allow_mounted_write=0 \ -group_reporting \ -direct=1 \ -offset_increment=1g \ -rw=randwrite \ -bs=1024k \ -numjobs={1,2,4,8,16,32,64,128,256,512} \ -runtime=110 \ -ramp_time=10 Test result: MiB/s | numjobs | v5.18-rc1 | v5.18-rc1-patched | | ------- | --------- | ----------------- | | 1 | 67.7 | 67.7 | | 2 | 67.7 | 67.7 | | 4 | 67.7 | 67.7 | | 8 | 67.7 | 67.7 | | 16 | 64.8 | 65.2 | | 32 | 59.8 | 62.8 | | 64 | 54.9 | 58.6 | | 128 | 49 | 55.8 | | 256 | 37.7 | 52.3 | | 512 | 31.8 | 51.4 | Yu Kuai (8): sbitmap: record the number of waiters for each waitqueue blk-mq: call 'bt_wait_ptr()' later in blk_mq_get_tag() sbitmap: make sure waitqueues are balanced blk-mq: don't preempt tag on heavy load sbitmap: force tag preemption if free tags are sufficient blk-mq: force tag preemption for split bios blk-mq: record how many tags are needed for splited bio sbitmap: wake up the number of threads based on required tags block/blk-merge.c | 9 ++- block/blk-mq-tag.c | 42 +++++++++----- block/blk-mq.c | 25 +++++++- block/blk-mq.h | 2 + include/linux/blk_types.h | 4 ++ include/linux/sbitmap.h | 9 +++ lib/sbitmap.c | 117 +++++++++++++++++++++++++------------- 7 files changed, 150 insertions(+), 58 deletions(-)