On Mon, Jan 03, 2022 at 12:12:50PM +0100, Ingo Molnar wrote: > * Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > This is "interesting", but how are you going to keep the > > kernel/sched/per_task_area_struct_defs.h and struct task_struct_per_task > > definition in sync? > > I have plans to clean this up further - see below - but in general I'd > *discourage* the embedding of new complex types to task_struct. > > In practice, most new task_struct fields are either simple types or > pointers to structs, which can be added to task_struct without having to > define a complex type for <linux/sched.h>. > > For example here's the list of the last 5 extensions of task_struct, since > November 2020 - I copy & pasted them out of git log -p include/linux/sched.h: > > + unsigned in_eventfd_signal:1; > > + cpumask_t *user_cpus_ptr; > > + unsigned int saved_state; > > + unsigned long saved_state_change; > > + struct bpf_run_ctx *bpf_ctx; > > All of those new fields are either simple C types or struct pointers - none > of those extensions need per_task() handling per se. > > 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 :) > > That issue aside, I took a glance at the tree, and overall it looks like > > a lot of nice cleanups. Most of these can probably go through the > > various subsystem trees, after you split them out, for the "major" .h > > cleanups. Is that something you are going to be planning on doing? > > Yeah, I absolutely plan on doing that too: > > - About ~70% of the commits can be split up & parallelized through > maintainer trees. > > - With the exception of the untangling of sched.h, per_task and the > "Optimize Headers" series, where a lot of patches are dependent on each > other. These are actually needed to get any measurable benefits from this > tree (!). We can do these through the scheduler tree, or through the > dedicated headers tree I posted. > > The latter monolithic series is pretty much unavoidable, it's the result of > 30 years of coupling a lot of kernel subsystems to task_struct via embedded > structs & other complex types, that needed quite a bit of effort to > untangle, and that untangling needed to happen in-order. > > Do these plans this 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. thanks, greg k-h
