[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <26da75a6-115f-a17a-73bb-381a6b4a3a75@linux.dev>
Date: Tue, 30 May 2023 11:07:29 +0800
From: Qi Zheng <qi.zheng@...ux.dev>
To: paulmck@...nel.org, Kirill Tkhai <tkhai@...ru>
Cc: RCU <rcu@...r.kernel.org>, Yujie Liu <yujie.liu@...el.com>,
oe-lkp@...ts.linux.dev, lkp@...el.com,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Christian König <christian.koenig@....com>,
David Hildenbrand <david@...hat.com>,
Davidlohr Bueso <dave@...olabs.net>,
Johannes Weiner <hannes@...xchg.org>,
Michal Hocko <mhocko@...nel.org>,
Muchun Song <muchun.song@...ux.dev>,
Shakeel Butt <shakeelb@...gle.com>,
Yang Shi <shy828301@...il.com>, linux-mm@...ck.org,
ying.huang@...el.com, feng.tang@...el.com, fengwei.yin@...el.com
Subject: Re: [linus:master] [mm] f95bdb700b: stress-ng.ramfs.ops_per_sec
-88.8% regression
Hi,
On 2023/5/29 20:51, Paul E. McKenney wrote:
> On Mon, May 29, 2023 at 10:39:21AM +0800, Qi Zheng wrote:
[...]
>>
>> Thanks for such a detailed explanation.
>>
>> Now I think we can continue to try to complete the idea[1] from
>> Kirill Tkhai. The patch moves heavy synchronize_srcu() to delayed
>> work, so it doesn't affect on user-visible unregistration speed.
>>
>> [1]. https://lore.kernel.org/lkml/153365636747.19074.12610817307548583381.stgit@localhost.localdomain/
>
> A blast from the past! ;-)
>
> But yes, moving the long-latency synchronize_srcu() off the user-visible
> critical code path can be even better.
Yeah, I applied these patches ([PATCH RFC 04/10]~[PATCH RFC 10/10],
with few conflicts), the ops/s does get back to the previous levels.
I'll continue updating this patchset after doing more testing.
Thanks,
Qi
>
> Thanx, Paul
Powered by blists - more mailing lists