* Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > The overall policy to extend task_struct, going forward, would be to: > > > > - Either make simple-type or struct-pointer additions to task_struct, that > > don't couple <linux/sched.h> to other subsystems. > > > > - Or, if you absolutely must - and we don't want to forbid this - use the > > per_task() machinery to create a simple accessor to a complex embedded > > type. > > I'll leave all of this up to the scheduler developers, but it still looks > odd to me. The mess we create trying to work around issues in C :) Yeah, so I *did* find this somewhat suboptimal too, and developed an earlier version that used linker section tricks to gain the field offsets more automatically. It was an unmitigated disaster: was fragile on x86 already (which has a zoo of linking quirks with no precedent of doing this before bounds.c processing), but on ARM64 and probably on most of the other RISC-ish architectures there was also a real runtime code generation cost of using linker tricks: 2-3 extra instructions per per_task() use - clearly unacceptable. Found this out the hard way after making it boot & work on ARM64 and looking at the assembly output, trying to figure out why the generated code size increased. :-/ Anyway, the current method has the big advantage of being obviously invariant wrt. code generation compared to the previous code, on every architecture. > > Do these plans sound good to you? > > Yes, taking the majority through the maintainer trees and then doing the > remaining bits in a single tree seems sane, that one tree will be easier > to review as well. Ok. Will definitely offer it up piecemail-wise, in reviewable chunks, via existing processes & flows. Thanks, Ingo
