cpu_active vs pcrypt & padata
Hi Steffen,
I found cpu_active usage in crypto/pcrypt.c and was wondering what that's doing there. I would really like to contain that thing to as narrow a piece of kernel as I possible can (sched/cpuset/hotplug) but it appears to be spreading.
Also, wth is all this kernel/padata.c stuff? There's next to no useful comment in there and the only consumer seems to be pcrypt, does that really need to be in kernel/ ?
From: Peter Zijlstra <[email protected]>
Date: Fri, 16 Mar 2012 11:13:08 +0100
Quoted 3 lines
Also, wth is all this
kernel/padata.cstuff? There's next to no useful comment in there and the only consumer seems to be pcrypt, does that really need to be inkernel/?
There's really nothing specific to crypto in that padata.c file, anything trying to compute things in parallel with some kind of converging synchronization points can use that code.
Quoted 10 lines · David Miller
From: Peter Zijlstra <[email protected]>
Date: Fri, 16 Mar 2012 11:13:08 +0100Quoted 3 lines
Also, wth is all this
kernel/padata.cstuff? There's next to no useful comment in there and the only consumer seems to be pcrypt, does that really need to be inkernel/?There's really nothing specific to crypto in that
padata.cfile, anything trying to compute things in parallel with some kind of converging synchronization points can use that code.
So why isn't anybody else using that? Don't the block/fs people need similar things?
From: Peter Zijlstra <[email protected]>
Date: Fri, 16 Mar 2012 11:20:15 +0100
Quoted 8 lines · David Miller
Quoted 7 lines
From: Peter Zijlstra <[email protected]>
Date: Fri, 16 Mar 2012 11:13:08 +0100Quoted 3 lines
Also, wth is all this
kernel/padata.cstuff? There's next to no useful comment in there and the only consumer seems to be pcrypt, does that really need to be inkernel/?
Quoted 6 lines
Quoted 3 lines
There's really nothing specific to crypto in that
padata.cfile, anything trying to compute things in parallel with some kind of converging synchronization points can use that code.So why isn't anybody else using that? Don't the block/fs people need similar things?
Beats me, but just because there's only one user doesn't mean it belongs tucked away in that one user's subsystem.
Quoted 2 lines · David Miller
Beats me, but just because there's only one user doesn't mean it belongs tucked away in that one user's subsystem.
Sure, but I was mostly wondering wth it was, the file doesn't really explain itself.
Also, most times when introducing generic functionality people try to collect all interested parties and make something that works for everybody.
I know for a fact that btrfs does the fan out and regroup thing for block checksumming etc.. Does Chris even know it exists? If he does why isn't brtfs using it? If its unsuitable, why wasn't it fixed.
I'm not saying its crap or anything -- I haven't looked at it at all, beyond my grep for cpu_active -- I'm just wondering, and so far it looks like there's something weird.
Hi.
Quoted 6 lines · Peter Zijlstra
Hi Steffen,
I found
cpu_activeusage incrypto/pcrypt.cand was wondering what that's doing there. I would really like to contain that thing to as narrow a piece of kernel as I possible can (sched/cpuset/hotplug) but it appears to be spreading.
pcrypt uses cpu_active to tell padata which cpuset it whishes to use for parallelization. I could try to push the cpumask handling down to padata if you want to limit this to the core kernel.
Quoted 4 lines
Also, wth is all this
kernel/padata.cstuff? There's next to no useful comment in there and the only consumer seems to be pcrypt, does that really need to be inkernel/?
The padata code is generic and not limited to crypto, you can find a documentation at Documentation/padata.txt.
Quoted 10 lines · Steffen Klassert
Hi.
Quoted 6 lines · Peter Zijlstra
Hi Steffen,
I found
cpu_activeusage incrypto/pcrypt.cand was wondering what that's doing there. I would really like to contain that thing to as narrow a piece of kernel as I possible can (sched/cpuset/hotplug) but it appears to be spreading.
Quoted 4 lines
pcrypt uses
cpu_activeto tell padata which cpuset it whishes to use for parallelization. I could try to push the cpumask handling down to padata if you want to limit this to the core kernel.
/me more confused now.. cpu_active isn't in any way shape or form related to cpusets.
Quoted 6 lines
Quoted 3 lines
Also, wth is all this
kernel/padata.cstuff? There's next to no useful comment in there and the only consumer seems to be pcrypt, does that really need to be inkernel/?The padata code is generic and not limited to crypto, you can find a documentation at
Documentation/padata.txt.
Would be nice to have a short blurb in kernel/padata.c with a reference to that Documentation stuff for more in-depth bits.
Quoted 9 lines · Peter Zijlstra
Quoted 5 lines · Steffen Klassert
pcrypt uses
cpu_activeto tell padata which cpuset it whishes to use for parallelization. I could try to push the cpumask handling down to padata if you want to limit this to the core kernel./me more confused now..
cpu_activeisn't in any way shape or form related to cpusets.
When looking at this, it seems that cpu_online_mask is the mask we should use instead of cpu_active_mask. I'll go in for a closer look at the end of the week.
Quoted 6 lines
Quoted 3 lines
The padata code is generic and not limited to crypto, you can find a documentation at
Documentation/padata.txt.Would be nice to have a short blurb in
kernel/padata.cwith a reference to that Documentation stuff for more in-depth bits.
Indeed, I'll take care for this.
Quoted 3 lines · On Fri, 16 Mar 2012 11:13:08 +0100 Peter Zijlstra <[email protected]> wrote:
Also, wth is all this
kernel/padata.cstuff? There's next to no useful comment in there and the only consumer seems to be pcrypt, does that really need to be inkernel/?
FWIW I wrote that stuff up when it went in...
https://lwn.net/Articles/382257/
Might be helpful in case anybody else thinks they might want to use this facility. Maybe.
jon