Issue: Can padata avoid dealing with CPU-related operations?
Hello, I have a few questions about the padata code I've been studying recently:
- Why does padata use the WQ_UNBOUND attribute of the workqueue? Because I've noticed a significant maintenance cost related to CPUs. Are there any specific benefits?
- In what scenarios is it necessary to specify a CPU for serial execution, or is ensuring the order sufficient?
In fact, the two questions can be summarized into one: Is it possible to avoid handling CPU-related operations to simplify the code logic?
Thanks.
Hi,
Quoted 4 lines · Wang Jinchao
Hello, I have a few questions about the padata code I've been studying recently:
- Why does padata use the
WQ_UNBOUNDattribute of the workqueue?
There's background in this series:
https://lore.kernel.org/all/[email protected]/
Quoted 2 lines
Because I've noticed a significant maintenance cost related to CPUs. Are there any specific benefits?
Aside from what Steffen said about serialization, the pcrypt cpumasks can be set from sysfs to control where parallel and serial jobs run.
Quoted 2 lines
- In what scenarios is it necessary to specify a CPU for serial execution, or is ensuring the order sufficient?
I'm not sure that it's necessary. The way I read it, at least, it seems pcrypt uses cb_cpu to load balance serialization across all CPUs allowed in the serial cpumask.
Quoted 11 lines · Daniel Jordan
Hi,
Quoted 4 lines · Wang Jinchao
Hello, I have a few questions about the padata code I've been studying recently:
- Why does padata use the
WQ_UNBOUNDattribute of the workqueue?There's background in this series:
https://lore.kernel.org/all/[email protected]/
Summarizing, the use of the WQ_UNBOUND attribute is primarily based on performance considerations. Is this understanding correct?
Quoted 6 lines
Quoted 2 lines
Because I've noticed a significant maintenance cost related to CPUs. Are there any specific benefits?
Aside from what Steffen said about serialization, the pcrypt cpumasks can be set from sysfs to control where parallel and serial jobs run.
Quoted 6 lines
Quoted 2 lines
- In what scenarios is it necessary to specify a CPU for serial execution, or is ensuring the order sufficient?
I'm not sure that it's necessary. The way I read it, at least, it seems pcrypt uses
cb_cputo load balance serialization across all CPUs allowed in the serial cpumask.
I recognize that the key issue isn't the capabilities it can offer, but rather the underlying necessity for these capabilities. If the need isn't particularly strong and the cost of implementing this capability is high, should we consider omitting it?
As previously mentioned in another email, I'm seeking guidance on how to effectively evaluate the timing of padata serialization in a network environment. Could you provide some insights or pointers on this matter?
Furthermore, I'd like to extend my sincere gratitude for your recent responses and would appreciate discussing my future steps with you.
Thank you.
Quoted 7 lines · Wang Jinchao
Quoted 6 lines · Daniel Jordan
Hi,
Quoted 3 lines · Wang Jinchao
Hello, I have a few questions about the padata code I've been studying recently:
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
- Why does padata use the
WQ_UNBOUNDattribute of the workqueue?There's background in this series:
https://lore.kernel.org/all/[email protected]/Summarizing, the use of the
WQ_UNBOUNDattribute is primarily based on performance considerations. Is this understanding correct?
Yes, it's entirely based on performance. In the tests I ran, padata did a lot better when it was free to run parallel works on any CPU in case some were busy.
Quoted 9 lines
Quoted 9 lines
Quoted 2 lines
Because I've noticed a significant maintenance cost related to CPUs. Are there any specific benefits?
Aside from what Steffen said about serialization, the pcrypt cpumasks can be set from sysfs to control where parallel and serial jobs run.
Quoted 2 lines
- In what scenarios is it necessary to specify a CPU for serial execution, or is ensuring the order sufficient?
Quoted 8 lines
Quoted 3 lines
I'm not sure that it's necessary. The way I read it, at least, it seems pcrypt uses
cb_cputo load balance serialization across all CPUs allowed in the serial cpumask.I recognize that the key issue isn't the capabilities it can offer, but rather the underlying necessity for these capabilities. If the need isn't particularly strong and the cost of implementing this capability is high, should we consider omitting it?
Well, yeah. In this case, I'm not sure it's necessary--it looks to me like it's not--but Steffen might have had a reason for cb_cpu that I'm not aware of.
Quoted 3 lines
As previously mentioned in another email, I'm seeking guidance on how to effectively evaluate the timing of padata serialization in a network environment. Could you provide some insights or pointers on this matter?
It looks like Steffen has given some hints on testing with IPsec in another thread.