Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1575164 > unrolled thread

Re: [PATCH 00/89] Major reorganization of <linux/sched.h>

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 00/89] Major reorganization of <linux/sched.h> Linus Torvalds <torvalds@linux-foundation.org> - 2017-02-06 22:40 +0100
    Re: [PATCH 00/89] Major reorganization of <linux/sched.h> Ingo Molnar <mingo@kernel.org> - 2017-02-06 23:20 +0100
      Re: [PATCH 00/89] Major reorganization of <linux/sched.h> Peter Zijlstra <peterz@infradead.org> - 2017-02-07 09:10 +0100

#1575164 — Re: [PATCH 00/89] Major reorganization of <linux/sched.h>

On Mon, Feb 6, 2017 at 5:28 AM, Ingo Molnar <mingo@kernel.org> wrote:
> So 25+ years ago, in Linux-0.01, include/linux/sched.h was already
> the biggest core kernel header file: [...]

Ok, so having tried to look through this series I do like it, but I'd
be *really* much happier if more of it was just verifiably a semantic
no-op.

There were all those small things in there (Peter pointed out those
cpumask things I wouldn't for the life of me have noticed) that were
really subtle, and were really hidden by the fact that there was just
a lot of non-semantic changes.

            Linus

[toc] | [next] | [standalone]

#1575203

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, Feb 6, 2017 at 5:28 AM, Ingo Molnar <mingo@kernel.org> wrote:
> > So 25+ years ago, in Linux-0.01, include/linux/sched.h was already
> > the biggest core kernel header file: [...]
> 
> Ok, so having tried to look through this series I do like it, but I'd be 
> *really* much happier if more of it was just verifiably a semantic no-op.

Yeah - that was the intention.

It's really hard to verify it in an automated fashion I think, in a cross arch 
way. I did a sizeof(task_struct) before/after check on x86 defconfig, which did 
not uncover the extra pointer on CONFIG_TASK_DELAY_ACCT=n, because defconfig has 
that enabled...

On the latest tree I've done a wider test of sizeof(task_struct):

		allnoconfig	defconfig	allmodconfig
  -----------------------------------------------------------
  before:	0x1400		0x19c0		0x3f00
  after:	0x1400		0x19c0		0x3f00

Which seems to support my intention that the series should be an overall invariant 
on 'struct task_struct' semantics.

> There were all those small things in there (Peter pointed out those cpumask 
> things I wouldn't for the life of me have noticed) that were really subtle, and 
> were really hidden by the fact that there was just a lot of non-semantic 
> changes.

I think the ->cpus_allowed bugs Peter noticed are pre-existing - that patch 
doesn't intend to make any semantic changes.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1575445

On Mon, Feb 06, 2017 at 11:13:59PM +0100, Ingo Molnar wrote:
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > There were all those small things in there (Peter pointed out those cpumask 
> > things I wouldn't for the life of me have noticed) that were really subtle, and 
> > were really hidden by the fact that there was just a lot of non-semantic 
> > changes.
> 
> I think the ->cpus_allowed bugs Peter noticed are pre-existing - that patch 
> doesn't intend to make any semantic changes.

Correct, those are pre-existing, just noticed then (again) because the
changes made me look at the code.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web