From: "D. Wythe" <alibuda@linux.alibaba.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: kgraul@linux.ibm.com, wenjia@linux.ibm.com, davem@davemloft.net,
netdev@vger.kernel.org, linux-s390@vger.kernel.org,
linux-rdma@vger.kernel.org
Subject: Re: [PATCH net-next v2 00/10] optimize the parallelism of SMC-R connections
Date: Mon, 29 Aug 2022 11:28:47 +0800 [thread overview]
Message-ID: <c2092a9e-16da-68fc-824b-65699430bb68@linux.alibaba.com> (raw)
In-Reply-To: <20220826183213.38eb4cac@kernel.org>
On 8/27/22 9:32 AM, Jakub Kicinski wrote:
> On Fri, 26 Aug 2022 17:51:27 +0800 D. Wythe wrote:
>> This patch set attempts to optimize the parallelism of SMC-R connections,
>> mainly to reduce unnecessary blocking on locks, and to fix exceptions that
>> occur after thoses optimization.
>>
>> According to Off-CPU graph, SMC worker's off-CPU as that:
>>
>> smc_close_passive_work (1.09%)
>> smcr_buf_unuse (1.08%)
>> smc_llc_flow_initiate (1.02%)
>>
>> smc_listen_work (48.17%)
>> __mutex_lock.isra.11 (47.96%)
>
> The patches should be ordered so that the prerequisite changes are
> first, then the removal of locks. Looks like there are 3 patches here
> which carry a Fixes tag, for an old commit but in fact IIUC there is no
> bug in those old commits, the problem only appears after the locking is
> removed?
>
Thank you for your suggestion, this is indeed my ill-consideration.
The first PATCH with the Fix tag is indeed a prerequisite for removing the lock,
and it do should be placed before. The other two with PATCH fixes theoretically
can also appear before, but after the lock is removed the probability of it will
be greatly increased. I see it can also be placed before.
> That said please wait for IBM folks to review first before reshuffling
> the patches, I presume the code itself won't change.
Thanks your suggestion again, I will reshuffling the order of it after you
have reviewed it all.
> Also I still haven't see anyone reply to Al Viro, IIRC he was
> complaining about changes someone from your team has made.
> I consider this a blocker for applying new patches from your team :(
Sorry to bother you and your team, my colleague will explain to you soon.
Thanks.
D. Wythe
next prev parent reply other threads:[~2022-08-29 3:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-26 9:51 [PATCH net-next v2 00/10] optimize the parallelism of SMC-R connections D. Wythe
2022-08-26 9:51 ` [PATCH net-next v2 01/10] net/smc: remove locks smc_client_lgr_pending and smc_server_lgr_pending D. Wythe
2022-08-29 14:48 ` Jan Karcher
2022-08-31 15:04 ` Jan Karcher
2022-09-02 11:25 ` D. Wythe
2022-09-07 8:10 ` Jan Karcher
2022-09-16 5:16 ` D. Wythe
2022-08-26 9:51 ` [PATCH net-next v2 02/10] net/smc: fix SMC_CLC_DECL_ERR_REGRMB without smc_server_lgr_pending D. Wythe
2022-08-26 9:51 ` [PATCH net-next v2 03/10] net/smc: allow confirm/delete rkey response deliver multiplex D. Wythe
2022-08-26 9:51 ` [PATCH net-next v2 04/10] net/smc: make SMC_LLC_FLOW_RKEY run concurrently D. Wythe
2022-08-26 9:51 ` [PATCH net-next v2 05/10] net/smc: llc_conf_mutex refactor, replace it with rw_semaphore D. Wythe
2022-08-26 9:51 ` [PATCH net-next v2 06/10] net/smc: use read semaphores to reduce unnecessary blocking in smc_buf_create() & smcr_buf_unuse() D. Wythe
2022-08-26 9:51 ` [PATCH net-next v2 07/10] net/smc: reduce unnecessary blocking in smcr_lgr_reg_rmbs() D. Wythe
2022-08-26 9:51 ` [PATCH net-next v2 08/10] net/smc: replace mutex rmbs_lock and sndbufs_lock with rw_semaphore D. Wythe
2022-08-26 9:51 ` [PATCH net-next v2 09/10] net/smc: Fix potential panic dues to unprotected smc_llc_srv_add_link() D. Wythe
2022-08-26 9:51 ` [PATCH net-next v2 10/10] net/smc: fix application data exception D. Wythe
2022-09-08 9:37 ` Wen Gu
2022-09-16 5:24 ` D. Wythe
2022-08-27 1:32 ` [PATCH net-next v2 00/10] optimize the parallelism of SMC-R connections Jakub Kicinski
2022-08-29 3:25 ` Tony Lu
2022-08-29 3:28 ` D. Wythe [this message]
2022-09-09 6:59 ` Jan Karcher
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=c2092a9e-16da-68fc-824b-65699430bb68@linux.alibaba.com \
--to=alibuda@linux.alibaba.com \
--cc=davem@davemloft.net \
--cc=kgraul@linux.ibm.com \
--cc=kuba@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=wenjia@linux.ibm.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).