All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	Christoph Lameter <cl@linux-foundation.org>
Subject: Re: [RFC] remove implicit slab.h inclusion from percpu.h
Date: Tue, 16 Mar 2010 15:54:02 +0900	[thread overview]
Message-ID: <4B9F2B0A.70507@kernel.org> (raw)
In-Reply-To: <20100316061718.GA22651@elte.hu>

Hello, Ingo.

On 03/16/2010 03:17 PM, Ingo Molnar wrote:
> ( /me mumbles something about not having a patch in the email to review and
>   pulling the tree. 200k patch is just fine for lkml - i've attached it below
>   for easier review. percpu.h and percpu.c has the meat of the changes. )

I wanted to keep the discussion high level while giving a general idea
about the extent of necessary changes.  I'll include the patch from
now on.

> i like the dependency reduction. Noticed one small detail:
> 
> this new 2000-lines #ifdef block percpu.c:
> 
>  +#ifdef CONFIG_SMP
>  +#else  /* CONFIG_SMP */
>  +#endif /* CONFIG_SMP */
> 
> feels a bit lame. A separate percpu_up.c file would be nicer i suppose?

Sure.

> Also, why should we make this opt-in and expose a wide range of configs to 
> build breakages? A more gradual approach would be to write a simple script 
> that adds a slab.h include to all .c's that include percpu.h, directly or 
> indirectly.
>
> You can map the pattern experimentally: the insertion pattern could be built 
> from the x86 allmodconfig build you did [i.e. extend the pattern until you 
> make it build on allmodconfig] - that would cover most cases in practice (not 
> just allmodconfig) - and would cover most architectures as well.

I don't really get the 'experimental' part but if I count all the
files which ends up including percpu.h directly or indirectly on
allmodconfig it ends up including much more .c files than necessasry -
11203 to be exact, ~20 times more than necessary.  Inclusions from .c
files definitely are much less troublesome so the situation would be
better than now but we'll still end up with a LOT of bogus inclusions
without any good way to eventually remove them.

Maybe a better way is to grab for slab API usages in .c files which
don't have slab.h inclusion.  If breaking the dependency is the way to
go, I can definitely write up some scripts and do test builds on some
archs.  There sure will be some fallouts but I think it won't be too
bad.

Thanks.

-- 
tejun

  reply	other threads:[~2010-03-16  6:54 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-11 14:56 [RFC] remove implicit slab.h inclusion from percpu.h Tejun Heo
2010-03-11 17:48 ` Alexey Dobriyan
2010-03-11 22:33   ` Tejun Heo
2010-03-16  4:27 ` Tejun Heo
2010-03-16  6:17   ` Ingo Molnar
2010-03-16  6:54     ` Tejun Heo [this message]
2010-03-16  7:44       ` Tejun Heo
2010-03-16  7:57         ` Ingo Molnar
2010-03-16  8:32           ` Alexey Dobriyan
2010-03-16  9:11             ` Pekka Enberg
2010-03-16  7:49       ` Ingo Molnar
2010-03-16  6:58     ` Pekka Enberg
2010-03-16  7:15       ` Alexey Dobriyan
2010-03-16  7:56         ` Pekka Enberg
2010-03-16  8:23           ` Alexey Dobriyan
2010-03-16  9:06             ` Pekka Enberg
2010-03-16  8:25           ` Ingo Molnar
2010-03-16  7:14     ` Alexey Dobriyan
2010-03-16  8:16       ` Ingo Molnar
2010-03-16 16:16 ` Christoph Lameter
2010-03-16 22:57   ` Tejun Heo
2010-03-17 16:34     ` Christoph Lameter
2010-03-17 17:14       ` Lee Schermerhorn
2010-03-17 19:54         ` Christoph Lameter
2010-03-17 23:00           ` Tejun Heo

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=4B9F2B0A.70507@kernel.org \
    --to=tj@kernel.org \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@linux-foundation.org \
    /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.