On 2022/9/19 17:11, Greg KH wrote:
On Mon, Sep 19, 2022 at 05:10:56PM +0800, Shang XiaoJing wrote:
Instead of invoking a synchronize_rcu() to free a pointer after a grace
period, we can directly make use of a new API that does the same but in
a more efficient way.
Signed-off-by: Shang XiaoJing <shangxiaojing@xxxxxxxxxx>
---
Changelog:
v3: the first version of the PATCH
v1: v3 resent as v1
v2: use kfree_rcu() instead of kvfree_rcu() for clarity
v4: resend v2 as v4 to avoid versioning confusion
---
drivers/staging/fwserial/fwserial.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/fwserial/fwserial.c b/drivers/staging/fwserial/fwserial.c
index 81b06d88ed0d..8d2b4ed1f39e 100644
--- a/drivers/staging/fwserial/fwserial.c
+++ b/drivers/staging/fwserial/fwserial.c
@@ -2117,8 +2117,7 @@ static void fwserial_remove_peer(struct fwtty_peer *peer)
if (port)
fwserial_release_port(port, true);
- synchronize_rcu();
- kfree(peer);
+ kfree_rcu(peer);
The kfree_rcu(peer) should be kfree_rcu(peer, rcu), due to the rcu_head
member named rcu in fwtty_peer.
This will be fixed in v5, sorry.
What is "more efficient" about this change?
kfree_rcu() will call kvfree_call_rcu, due to the note in kernel/rcu/tree.c:
/Each kvfree_call_rcu() request is added to a batch. The batch will be
drained every KFREE_DRAIN_JIFFIES number of jiffies. All the objects in
the batch will be free'd in workqueue context. This allows us to: batch
requests together to reduce the number of grace periods during heavy
kfree_rcu()/kvfree_rcu() load. ///
which is the reason I use "more efficient".
And do you have the hardware for this device to test with? It would be
good to finally get this out of staging, or to just remove it entirely
if no one uses it.
Actually, not. I just found the code here may be optimized.
thanks,
greg k-h
Thanks,
Shang XiaoJing
