1. 27 11月, 2010 1 次提交
    • M
      crypto: aesni-intel - Ported implementation to x86-32 · 0d258efb
      Mathias Krause 提交于
      The AES-NI instructions are also available in legacy mode so the 32-bit
      architecture may profit from those, too.
      
      To illustrate the performance gain here's a short summary of a dm-crypt
      speed test on a Core i7 M620 running at 2.67GHz comparing both assembler
      implementations:
      
      x86:                   i568       aes-ni    delta
      ECB, 256 bit:     93.8 MB/s   123.3 MB/s   +31.4%
      CBC, 256 bit:     84.8 MB/s   262.3 MB/s  +209.3%
      LRW, 256 bit:    108.6 MB/s   222.1 MB/s  +104.5%
      XTS, 256 bit:    105.0 MB/s   205.5 MB/s   +95.7%
      
      Additionally, due to some minor optimizations, the 64-bit version also
      got a minor performance gain as seen below:
      
      x86-64:           old impl.    new impl.    delta
      ECB, 256 bit:    121.1 MB/s   123.0 MB/s    +1.5%
      CBC, 256 bit:    285.3 MB/s   290.8 MB/s    +1.9%
      LRW, 256 bit:    263.7 MB/s   265.3 MB/s    +0.6%
      XTS, 256 bit:    251.1 MB/s   255.3 MB/s    +1.7%
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Reviewed-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      0d258efb
  2. 13 11月, 2010 1 次提交
  3. 28 10月, 2010 4 次提交
  4. 27 10月, 2010 8 次提交
  5. 26 10月, 2010 3 次提交
  6. 25 10月, 2010 1 次提交
    • I
      x86/oprofile: Fix uninitialized variable use in debug printk · 2c78ffec
      Ingo Molnar 提交于
      Stephen Rothwell reported this build warning:
      
        arch/x86/oprofile/op_model_amd.c: In function 'ibs_eilvt_valid':
        arch/x86/oprofile/op_model_amd.c:289: warning: 'offset' may be used uninitialized in this function
      
      And correctly observed that indeed the variable is used uninitialized in
      this function. The result of this bug can be a debug printk with a bogus
      value.
      
      Also fix a few more small details that made this function hard to read
      and which probably contributed to the bug being introduced to begin with:
      
       - Use more symmetric error conditions
      
       - Remove the !0 obfuscation
      
       - Add newlines to the printk output
      
       - Remove bogus linebreaks in printk strings and elsewhere
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <20101025115736.41d51abe.sfr@canb.auug.org.au>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2c78ffec
  7. 24 10月, 2010 22 次提交