[lkml]   [2022]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0000/2297] [ANNOUNCE, RFC] "Fast Kernel Headers" Tree -v1: Eliminate the Linux kernel's "Dependency Hell"
On Mon, Jan 03, 2022 at 12:12:50PM +0100, Ingo Molnar wrote:
> * Greg Kroah-Hartman <> 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.


greg k-h

 \ /
  Last update: 2022-01-03 14:46    [W:0.150 / U:0.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site