1. 20 9月, 2010 1 次提交
  2. 17 2月, 2010 1 次提交
    • T
      percpu: add __percpu sparse annotations to what's left · a29d8b8e
      Tejun Heo 提交于
      Add __percpu sparse annotations to places which didn't make it in one
      of the previous patches.  All converions are trivial.
      
      These annotations are to make sparse consider percpu variables to be
      in a different address space and warn if accessed without going
      through percpu accessors.  This patch doesn't affect normal builds.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NBorislav Petkov <borislav.petkov@amd.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Neil Brown <neilb@suse.de>
      a29d8b8e
  3. 19 10月, 2009 1 次提交
  4. 03 10月, 2009 1 次提交
  5. 06 8月, 2009 1 次提交
  6. 22 7月, 2009 1 次提交
  7. 15 7月, 2009 1 次提交
  8. 14 7月, 2009 4 次提交
  9. 02 6月, 2009 1 次提交
  10. 19 2月, 2009 1 次提交
    • H
      crypto: cryptd - Per-CPU thread implementation based on kcrypto_wq · 254eff77
      Huang Ying 提交于
      Original cryptd thread implementation has scalability issue, this
      patch solve the issue with a per-CPU thread implementation.
      
      struct cryptd_queue is defined to be a per-CPU queue, which holds one
      struct cryptd_cpu_queue for each CPU. In struct cryptd_cpu_queue, a
      struct crypto_queue holds all requests for the CPU, a struct
      work_struct is used to run all requests for the CPU.
      
      Testing based on dm-crypt on an Intel Core 2 E6400 (two cores) machine
      shows 19.2% performance gain. The testing script is as follow:
      
      -------------------- script begin ---------------------------
      #!/bin/sh
      
      dmc_create()
      {
              # Create a crypt device using dmsetup
              dmsetup create $2 --table "0 `blockdev --getsize $1` crypt cbc(aes-asm)?cryptd?plain:plain babebabebabebabebabebabebabebabe 0 $1 0"
      }
      
      dmsetup remove crypt0
      dmsetup remove crypt1
      
      dd if=/dev/zero of=/dev/ram0 bs=1M count=4 >& /dev/null
      dd if=/dev/zero of=/dev/ram1 bs=1M count=4 >& /dev/null
      
      dmc_create /dev/ram0 crypt0
      dmc_create /dev/ram1 crypt1
      
      cat >tr.sh <<EOF
      #!/bin/sh
      
      for n in \$(seq 10); do
              dd if=/dev/dm-0 of=/dev/null >& /dev/null &
              dd if=/dev/dm-1 of=/dev/null >& /dev/null &
      done
      wait
      EOF
      
      for n in $(seq 10); do
              /usr/bin/time sh tr.sh
      done
      rm tr.sh
      -------------------- script end   ---------------------------
      
      The separator of dm-crypt parameter is changed from "-" to "?", because
      "-" is used in some cipher driver name too, and cryptds need to specify
      cipher driver name instead of cipher name.
      
      The test result on an Intel Core2 E6400 (two cores) is as follow:
      
      without patch:
      -----------------wo begin --------------------------
      0.04user 0.38system 0:00.39elapsed 107%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6566minor)pagefaults 0swaps
      0.07user 0.35system 0:00.35elapsed 121%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6567minor)pagefaults 0swaps
      0.06user 0.34system 0:00.30elapsed 135%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6562minor)pagefaults 0swaps
      0.05user 0.37system 0:00.36elapsed 119%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6607minor)pagefaults 0swaps
      0.06user 0.36system 0:00.35elapsed 120%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6562minor)pagefaults 0swaps
      0.05user 0.37system 0:00.31elapsed 136%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6594minor)pagefaults 0swaps
      0.04user 0.34system 0:00.30elapsed 126%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6597minor)pagefaults 0swaps
      0.06user 0.32system 0:00.31elapsed 125%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6571minor)pagefaults 0swaps
      0.06user 0.34system 0:00.31elapsed 134%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6581minor)pagefaults 0swaps
      0.05user 0.38system 0:00.31elapsed 138%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6600minor)pagefaults 0swaps
      -----------------wo end   --------------------------
      
      
      with patch:
      ------------------w begin --------------------------
      0.02user 0.31system 0:00.24elapsed 141%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6554minor)pagefaults 0swaps
      0.05user 0.34system 0:00.31elapsed 127%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6606minor)pagefaults 0swaps
      0.07user 0.33system 0:00.26elapsed 155%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6559minor)pagefaults 0swaps
      0.07user 0.32system 0:00.26elapsed 151%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6562minor)pagefaults 0swaps
      0.05user 0.34system 0:00.26elapsed 150%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6603minor)pagefaults 0swaps
      0.03user 0.36system 0:00.31elapsed 124%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6562minor)pagefaults 0swaps
      0.04user 0.35system 0:00.26elapsed 147%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6586minor)pagefaults 0swaps
      0.03user 0.37system 0:00.27elapsed 146%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6562minor)pagefaults 0swaps
      0.04user 0.36system 0:00.26elapsed 154%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6594minor)pagefaults 0swaps
      0.04user 0.35system 0:00.26elapsed 154%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+6557minor)pagefaults 0swaps
      ------------------w end   --------------------------
      
      The middle value of elapsed time is:
      wo cryptwq: 0.31
      w  cryptwq: 0.26
      
      The performance gain is about (0.31-0.26)/0.26 = 0.192.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      254eff77
  11. 18 2月, 2009 1 次提交
  12. 10 7月, 2008 3 次提交
  13. 01 5月, 2008 1 次提交
  14. 08 2月, 2008 1 次提交
  15. 11 1月, 2008 2 次提交
    • H
      [CRYPTO] cryptd: Use geniv of the underlying algorithm · 927eead5
      Herbert Xu 提交于
      If the underlying algorithm specifies a specific geniv algorithm then
      we should use it for the cryptd version as well.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      927eead5
    • H
      [CRYPTO] ablkcipher: Add distinct ABLKCIPHER type · 332f8840
      Herbert Xu 提交于
      Up until now we have ablkcipher algorithms have been identified as
      type BLKCIPHER with the ASYNC bit set.  This is suboptimal because
      ablkcipher refers to two things.  On the one hand it refers to the
      top-level ablkcipher interface with requests.  On the other hand it
      refers to and algorithm type underneath.
      
      As it is you cannot request a synchronous block cipher algorithm
      with the ablkcipher interface on top.  This is a problem because
      we want to be able to eventually phase out the blkcipher top-level
      interface.
      
      This patch fixes this by making ABLKCIPHER its own type, just as
      we have distinct types for HASH and DIGEST.  The type it associated
      with the algorithm implementation only.
      
      Which top-level interface is used for synchronous block ciphers is
      then determined by the mask that's used.  If it's a specific mask
      then the old blkcipher interface is given, otherwise we go with the
      new ablkcipher interface.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      332f8840
  16. 11 10月, 2007 1 次提交
  17. 31 5月, 2007 1 次提交
  18. 02 5月, 2007 1 次提交