All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Jeff Garzik <jeff@garzik.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Mike Travis <travis@sgi.com>, LKML <linux-kernel@vger.kernel.org>,
	viro@zeniv.linux.org.uk,
	Andrew Morton <akpm@linux-foundation.org>,
	roland@redhat.com
Subject: Re: [RFC PATCH 2/2] kernel/sched.c: VLA in middle of struct
Date: Tue, 12 May 2009 10:54:02 +0200	[thread overview]
Message-ID: <20090512085402.GA18004@elte.hu> (raw)
In-Reply-To: <4A08DDE2.1080708@garzik.org>


* Jeff Garzik <jeff@garzik.org> wrote:

> Ingo Molnar wrote:
>>>>>> That cpumask[] should probably be cpumask[0], to document the
>>>>>> aliasing to ->span and ->cpus properly.
>>>>> If the comment wasn't sufficient documentation, I don't think 
>>>>> that  would help :(
>>>> It's a visual helper: it matches up with how we do these 'zero size 
>>>>  array means dynamic structure continuation' tricks generally.
>>>>
>>>> I first mis-parsed the code for a second when seeing cpumask[].   
>>>> cpumask[0] stands out like a sore thumb. And we dont read comments  
>>>> anyway ;-)
>>>>
>>>> Jeff, i suspect you found this because you are working on something 
>>>>  rather interesting? :) If yes, would it help your project if we 
>>>> did  the cpumask[0] cleanup and pushed it upstream immediately?
>>> I think cpumask[0] would be more clear and consistent with the rest 
>>> of the kernel.
>>>
>>> But unfortunately for the twin projects of (a) static analysis and  
>>> checking with 'sparse', and (b) compiling under another compiler,  
>>> VLA-in-middle-of-struct is a killer in either case.
>>
>> even if at the end of the struct?
>
> Putting the VLA at the end of the struct would be a huge help, 
> yes.
>
> For example, struct sched_group and struct sched_domain are OK 
> as-is (though "[0]" would be preferred).
>
> It is the definition of struct static_sched_group and struct 
> static_sched_domain that creates the problem, because with the 
> bitmap following cpumask[] and span[], the VLA is no longer at the 
> end of the struct.
>
> VLA-in-the-middle raises the complexity required of the compiler 
> quite a bit.  As a result, VLA-in-middle is not implemented in 
> sparse or clang (LLVM's C front-end and static analyzer).

feel free to send patches for this - i dont have those build modes 
to test that it's sufficient. I'd suggest to go the simplest path: 
remove all the vla aliasing tricks: just make struct sched_domain 
use a plain struct cpumask and eliminate static_sched_domain 
altogether.

The memory overhead is marginal as most of our sched domains are 
static allocated (and full size) anyway.

	Ingo

  reply	other threads:[~2009-05-12  8:55 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-08 18:48 [PATCH 1/2] kernel/{sched,smp}.c: fix static decl prior to struct declaration Jeff Garzik
2009-05-08 18:50 ` [RFC PATCH 2/2] kernel/sched.c: VLA in middle of struct Jeff Garzik
2009-05-08 19:09   ` Ingo Molnar
2009-05-10  8:49     ` Rusty Russell
2009-05-10 15:09       ` Jeff Garzik
2009-05-12 13:34         ` Rusty Russell
2009-05-12 14:03           ` Al Viro
2009-05-13  2:12             ` Rusty Russell
2009-05-13  2:31               ` Jeff Garzik
2009-05-13  5:36               ` Al Viro
2009-05-13  6:49                 ` [PATCH] sched: avoid flexible array member inside struct (gcc extension) Rusty Russell
2009-05-13 13:51                   ` [tip:sched/urgent] " tip-bot for Rusty Russell
2009-05-11 10:58       ` [RFC PATCH 2/2] kernel/sched.c: VLA in middle of struct Ingo Molnar
2009-05-11 20:43         ` Jeff Garzik
2009-05-11 20:49           ` Ingo Molnar
2009-05-12  2:24             ` Jeff Garzik
2009-05-12  8:54               ` Ingo Molnar [this message]
2009-05-08 19:04 ` [PATCH 1/2] kernel/{sched,smp}.c: fix static decl prior to struct declaration Ingo Molnar
2009-05-08 19:08   ` Jeff Garzik
2009-05-08 19:13     ` Ingo Molnar
2009-05-08 19:38 ` [PATCH 1/2 v2] " Jeff Garzik
2009-05-11 11:26   ` Ingo Molnar
2009-05-11 20:06     ` Jeff Garzik
2009-05-11 20:51       ` Ingo Molnar
2009-05-11 11:30   ` [tip:sched/core] kernel/{sched, smp}.c: " tip-bot for Jeff Garzik
2009-05-11 20:02   ` [PATCH 1/2 v3] kernel/{sched,smp}.c: " Jeff Garzik
2009-05-11 21:51     ` [tip:sched/urgent] kernel/{sched, smp}.c: " tip-bot for Jeff Garzik
2009-05-11 21:56       ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090512085402.GA18004@elte.hu \
    --to=mingo@elte.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roland@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --cc=travis@sgi.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.