RFC Implement per-processor data areas for i386.
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 6 patches 1 replyIn review
Patches in v1 No applies recorded yet
None of the 6 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH RFC 0/6] 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