1. 02 7月, 2010 1 次提交
    • C
      kbuild: Warn on selecting symbols with unmet direct dependencies · 246cf9c2
      Catalin Marinas 提交于
      The "select" statement in Kconfig files allows the enabling of options
      even if they have unmet direct dependencies (i.e. "depends on" expands
      to "no"). Currently, the "depends on" clauses are used in calculating
      the visibility but they do not affect the reverse dependencies in any
      way.
      
      The patch introduces additional tracking of the "depends on" statements
      and prints a warning on selecting an option if its direct dependencies
      are not met.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      246cf9c2
  2. 02 2月, 2010 1 次提交
    • A
      Improve kconfig symbol hashing · e66f25d7
      Andi Kleen 提交于
      While looking for something else I noticed that the symbol
      hash function used by kconfig is quite poor. It doesn't
      use any of the standard hash techniques but simply
      adds up the string and then uses power of two masking,
      which is both known to perform poorly.
      
      The current x86 kconfig has over 7000 symbols.
      
      When I instrumented it showed that the minimum hash chain
      length was 16 and a significant number of them was over
      30.
      
      It didn't help that the hash table size was only 256 buckets.
      
      This patch increases the hash table size to a larger prime
      and switches to a FNV32 hash. I played around with a couple of hash
      functions, but that one seemed to perform best with reasonable
      hash table sizes.
      
      Increasing the hash table size even further didn't
      seem like a good idea, because there are a couple of global
      walks which walk the complete hash table.
      
      I also moved the unnamed bucket to 0. It's still the longest
      of all the buckets (44 entries), but hopefully it's not
      often hit except for the global walk which doesn't care.
      
      The result is a much nicer distribution:
      (first column bucket length, second number of buckets with that length)
      
      1: 3505
      2: 1236
      3: 294
      4: 52
      5: 3
      47: 1		<--- this is the unnamed symbols bucket
      
      There are still some 5+ buckets, but increasing the hash table
      even more would be likely not worth it.
      
      This also cleans up the code slightly by removing hard coded
      magic numbers.
      
      I didn't notice a big performance difference either way
      on my Nehalem system, but I presume it'll help somewhat
      on slower systems.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      e66f25d7
  3. 03 1月, 2009 3 次提交
  4. 29 1月, 2008 4 次提交
  5. 26 7月, 2007 2 次提交
  6. 09 6月, 2006 5 次提交
  7. 09 11月, 2005 1 次提交
    • D
      [PATCH] kconfig: Fix Kconfig performance bug · 3f04e7dd
      David Gibson 提交于
      When doing its recursive dependency check, scripts/kconfig/conf uses the flag
      SYMBOL_CHECK_DONE to avoid rechecking a symbol it has already checked.
      However, that flag is only set at the top level, so if a symbol is first
      encountered as a dependency of another symbol it will be rechecked every time
      it is encountered until it's encountered at the top level.
      
      This patch adjusts the flag setting so that each symbol will only be checked
      once, regardless of whether it is first encountered at the top level, or while
      recursing down from another symbol.  On complex configurations, this vastly
      speeds up scripts/kconfig/conf.  The config in the powerpc merge tree is
      particularly bad: this patch reduces the time for 'scripts/kconfig/conf -o
      arch/powerpc/Kconfig' by a factor of 40 on a G5.  That's even including the
      time to print the config, so the speedup in the actual checking is more likely
      2 or 3 orders of magnitude.
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3f04e7dd
  8. 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