Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 25 8月, 2016 1 次提交
    • A
      fixdep: faster CONFIG_ search · dee81e98
      由 Alexey Dobriyan 提交于 
      Do you think kernel build is 100% dominated by gcc? You are wrong!
One small utility called "fixdep" consistently manages to sneak into
profile's first page (unless you have small monitor of course).

The choke point is this clever code:

	for (; m < end; m++) {
		if (*m == INT_CONF) { p = (char *) m  ; goto conf; }
		if (*m == INT_ONFI) { p = (char *) m-1; goto conf; }
		if (*m == INT_NFIG) { p = (char *) m-2; goto conf; }
		if (*m == INT_FIG_) { p = (char *) m-3; goto conf; }

4 branches per 4 characters is not fast.

Use strstr(3), so that SSE2 etc can be used.

With this patch, fixdep is so deep at the bottom, it is hard to find it.
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NMichal Marek <mmarek@suse.com>
      dee81e98
  3. 30 3月, 2016 2 次提交
    • N
      kbuild: add fine grained build dependencies for exported symbols · c1a95fda
      由 Nicolas Pitre 提交于 
      Like with kconfig options, we now have the ability to compile in and
out individual EXPORT_SYMBOL() declarations based on the content of
include/generated/autoksyms.h.  However we don't want the entire
world to be rebuilt whenever that file is touched.

Let's apply the same build dependency trick used for CONFIG_* symbols
where the time stamp of empty files whose paths matching those symbols
is used to trigger fine grained rebuilds. In our case the key is the
symbol name passed to EXPORT_SYMBOL().

However, unlike config options, we cannot just use fixdep to parse
the source code for EXPORT_SYMBOL(ksym) because several variants exist
and parsing them all in a separate tool, and keeping it in synch, is
not trivially maintainable.  Furthermore, there are variants such as

	EXPORT_SYMBOL_GPL(pci_user_read_config_##size);

that are instanciated via a macro for which we can't easily determine
the actual exported symbol name(s) short of actually running the
preprocessor on them.

Storing the symbol name string in a special ELF section doesn't work
for targets that output assembly or preprocessed source.

So the best way is really to leverage the preprocessor by having it
output actual symbol names anchored by a special sequence that can be
easily filtered out. Then the list of symbols is simply fed to fixdep
to be merged with the other dependencies.

That implies the preprocessor is executed twice for each source file.
A previous attempt relied on a warning pragma for each EXPORT_SYMBOL()
instance that was filtered apart from stderr by the build system with
a sed script during the actual compilation pass. Unfortunately the
preprocessor/compiler diagnostic output isn't stable between versions
and this solution, although more efficient, was deemed too fragile.

Because of the lowercasing performed by fixdep, there might be name
collisions triggering spurious rebuilds for similar symbols. But this
shouldn't be a big issue in practice. (This is the case for CONFIG_*
symbols and I didn't want to be different here, whatever the original
reason for doing so.)

To avoid needless build overhead, the exported symbol name gathering is
performed only when CONFIG_TRIM_UNUSED_KSYMS is selected.
Signed-off-by: NNicolas Pitre <nico@linaro.org>
Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      c1a95fda
    • N
      fixdep: accept extra dependencies on stdin · d8329e35
      由 Nicolas Pitre 提交于 
      ... and merge them in the list of parsed dependencies.
Signed-off-by: NNicolas Pitre <nico@linaro.org>
      d8329e35
  5. 18 2月, 2016 1 次提交
  7. 07 12月, 2015 1 次提交
  9. 24 8月, 2015 2 次提交
  11. 10 6月, 2014 1 次提交
  13. 06 4月, 2013 1 次提交
    • S
      kbuild: fixdep: support concatenated dep files · 2ab8a996
      由 Stephen Warren 提交于 
      The current use-case for fixdep is: a source file is run through a single
processing step, which creates a single dependency file as a side-effect,
which fixdep transforms into the file used by the kernel build process.

In order to transparently run the C pre-processor on device-tree files,
we wish to run both gcc -E and dtc on a source file in a single rule.
This generates two dependency files, which must be transformed together
into the file used by the kernel build process. This change modifies
fixdep so it can process the concatenation of multiple separate input
dependency files, and produce a correct unified output.

The code changes have the slight benefit of transforming the loop in
parse_dep_file() into more of a lexer/tokenizer, with the loop body being
more of a parser. Previously, some of this logic was mixed together
before the loop. I also added some comments, which I hope are useful.

Benchmarking shows that on a cross-compiled ARM tegra_defconfig build,
there is less than 0.5 seconds speed decrease with this change, on top
of a build time of ~2m24s. This is probably within the noise.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NRob Herring <rob.herring@calxeda.com>
      2ab8a996
  15. 09 1月, 2013 1 次提交
  17. 09 9月, 2011 1 次提交
  19. 14 3月, 2011 1 次提交
  21. 21 2月, 2011 1 次提交
  23. 23 12月, 2010 1 次提交
  25. 12 11月, 2010 1 次提交
    • E
      fixdep: use hash table instead of a single array · 8af27e1d
      由 Eric Dumazet 提交于 
      I noticed fixdep uses ~2% of cpu time in kernel build, in function
use_config()

fixdep spends a lot of cpu cycles in linear searches in its internal
string array. With about 400 stored strings per dep file, this begins to
be noticeable.

Convert fixdep to use a hash table.

kbuild results on my x86_64 allmodconfig

Before patch :

real	10m30.414s
user	61m51.456s
sys	8m28.200s

real	10m12.334s
user	61m50.236s
sys	8m30.448s

real	10m42.947s
user	61m50.028s
sys	8m32.380s

After:

real	10m8.180s
user	61m22.506s
sys	8m32.384s

real	10m35.039s
user	61m21.654s
sys	8m32.212s

real	10m14.487s
user	61m23.498s
sys	8m32.312s
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>
      8af27e1d
  27. 12 12月, 2009 1 次提交
  29. 21 9月, 2009 2 次提交
  31. 20 9月, 2009 1 次提交
  33. 15 6月, 2009 1 次提交
  35. 03 5月, 2007 1 次提交
  37. 02 4月, 2007 1 次提交
    • J
      [PATCH] kbuild: fix dependency generation · c21b1e4d
      由 Jan Beulich 提交于 
      Commit 2e3646e5 changed the way the
split config tree is built, but failed to also adjust fixdep accordingly
- if changing a config option from or to m, files referencing the
respective CONFIG_..._MODULE (but not the corresponding CONFIG_...)
didn't get rebuilt.

The problem is that trisate symbol are represent with three different
symbols:
    SYMBOL=n => no symbol defined
    SYMBOL=y => CONFIG_SYMBOL defined to '1'
    SYMBOL=m => CONFIG_SYMBOL_MODULE defined to '1'

But conf_split_config do not distingush between the =y and =m case, so
only the =y case is honoured.

This is fixed in fixdep so when a CONFIG symbol with _MODULE is found we
skip that part and only look for the CONFIG_SYMBOL version.
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c21b1e4d
  39. 19 2月, 2006 1 次提交
    • J
      kbuild: consolidate command line escaping · 6176aa9a
      由 Jan Beulich 提交于 
      While the recent change to also escape # symbols when storing C-file
compilation command lines was helpful, it should be in effect for all
command lines, as much as the dollar escaping should be in effect for
C-source compilation commands. Additionally, for better readability and
maintenance, consolidating all the escaping (single quotes, dollars,
and now sharps) was also desirable.
Signed-Off-By: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      6176aa9a
  41. 26 12月, 2005 1 次提交
  43. 26 6月, 2005 1 次提交
  45. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      由 Linus Torvalds 提交于 
      Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
      1da177e4