Implement per-processor data areas for i386.
cover Implement per-processor data areas for i386.
In-Reply-To: <[email protected]>
Quoted 2 lines · Jeremy Fitzhardinge
This patch implements per-processor data areas by using %gs as the base segment of the per-processor memory.
This changes the ABI for signals and ptrace() and that seems like a bad idea to me.
And the way things are done now is so ingrained into the i386 kernel that I'm not sure it can be done. E.g. I found two open-coded implementations of current, one in kernel_fpu_begin() and one in math_state_restore().
Quoted 3 lines
- It also allows per-CPU data to be allocated as each CPU is brought up, rather than statically allocating it based on the maximum number of CPUs which could be brought up.
Can you describe what it is about the way things work now that prevents dynamic allocation?
Signature · 1 line
Chuck
Quoted 6 lines · Chuck Ebbert
Quoted 3 lines
This patch implements per-processor data areas by using %gs as the base segment of the per-processor memory.
This changes the ABI for signals and
ptrace()and that seems like a bad idea to me.
I don't believe it does; it certainly shouldn't change the usermode ABI. How do you see it changing?
Quoted 5 lines
And the way things are done now is so ingrained into the i386 kernel that I'm not sure it can be done. E.g. I found two open-coded implementations of current, one in
kernel_fpu_begin()and one inmath_state_restore().
That's OK. The current task will still be available in thread_info; this is needed for very early CPU bringup anyway, before the PDA has been set up. The vast majority of "get current task" operations can be swept up by changing "current" however.
Quoted 3 lines
Can you describe what it is about the way things work now that prevents dynamic allocation?
To be honest, I haven't looked at percpu.h in great detail. I was making assumptions about how it works, but it looks like they were wrong.
J