linux-kernel - Re: [RFC/PULL 00/11] introduce export.h; reduce module.h usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110728152753.GA19409@windriver.com>
Date:	Thu, 28 Jul 2011 11:27:53 -0400
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	<mingo@...e.hu>, <linux-kernel@...r.kernel.org>,
	<akpm@...ux-foundation.org>, <linux-arch@...r.kernel.org>
Subject: Re: [RFC/PULL 00/11] introduce export.h; reduce module.h usage

[Re: [RFC/PULL 00/11] introduce export.h; reduce module.h usage] On 28/07/2011 (Thu 06:19) Linus Torvalds wrote:

> On Wed, Jul 27, 2011 at 10:16 PM, Paul Gortmaker
> <paul.gortmaker@...driver.com> wrote:
> >
> > For all 160 commits, the branch "module.h-split", available here:
> >
> >        git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git
> >
> > has the complete content.  I've put the header changes after all the
> > patches from the top 5 categories, so that people bisecting non related
> > issues at a later date don't get hit with a commit zone with build failures.
> 
> Ok, sounds good. Two questions:
> 
>  - how much testing (randconfig? different architectures?) has this gotten?

I built allyeconfigs for arm, mips, powerpc, sparc, x86, x86-64.
Originally I was working on a v3.0-rc7 baseline, but after looking
at the new implicit module.h usages added since then, it was apparent
that I should update the baseline.

So I've re-run the multi-arch allyesconfigs to catch those new ones,
but with fallout from completely non related stuff, the allyesconfigs
on the non x86 variants don't build as far on the new v3.0-5684-ge371d46
baseline as they did on the 3.0-rc7 (to be expected in a tree leading up
to an rc1 release).

> 
>  - how much does this actually improve compile times (for a "normal"
> build or a "allmodconfig" one)?

Let me run some "real world" use cases and get back to you in a couple
of hours with that.  But Ingo's testing on a much earlier snapshot was
showing roughly a couple percent.  ( https://lkml.org/lkml/2011/5/28/60 )

> It certainly sounds like the RightThing(tm) to do, but I'd like to
> know that there is real actual improvements to build times and that
> the pain won't be too bad...

Yes, I've spent a lot of time fixing as many implicit users (thousands)
to try and minimize the pain here.  But I'd be a fool to think I have
them all fixed in the less mainstream architectures (alpha, sh, etc.)

And I know mips and arm have quite a few files that are platform specific
in mach-* and plat-* and they might not all get coverage via allyesconfig.
That is one place where I can think of that I am going to expand even
more testing into today.  Adding it to linux-next can't hurt either.

Thanks,
Paul.

> 
>              Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/