1. 04 3月, 2009 1 次提交
  2. 22 2月, 2009 1 次提交
    • A
      hwrng: timeriomem - New driver · 9c3c133b
      Alexander Clouter 提交于
      Some hardware platforms, the TS-7800[1] is one for example, can
      supply the kernel with an entropy source, albeit a slow one for
      TS-7800 users, by just reading a particular IO address.  This
      source must not be read above a certain rate otherwise the quality
      suffers.
      
      The driver is then hooked into by calling
      platform_device_(register|add|del) passing a structure similar to:
      ------
      static struct timeriomem_rng_data ts78xx_ts_rng_data = {
              .address        = (u32 *__iomem) TS_RNG,
              .period         = 1000000, /* one second */
      };
      
      static struct platform_device ts78xx_ts_rng_device = {
              .name           = "timeriomem_rng",
              .id             = -1,
              .dev            = {
                      .platform_data  = &ts78xx_ts_rng_data,
              },
              .num_resources  = 0,
      };
      ------
      
      [1] http://www.embeddedarm.com/products/board-detail.php?product=TS-7800Signed-off-by: NAlexander Clouter <alex@digriz.org.uk>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      9c3c133b
  3. 19 2月, 2009 3 次提交
    • H
      crypto: chainiv - Use kcrypto_wq instead of keventd_wq · 0a2e821d
      Huang Ying 提交于
      keventd_wq has potential starvation problem, so use dedicated
      kcrypto_wq instead.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      0a2e821d
    • 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
    • H
      crypto: api - Use dedicated workqueue for crypto subsystem · 25c38d3f
      Huang Ying 提交于
      Use dedicated workqueue for crypto subsystem
      
      A dedicated workqueue named kcrypto_wq is created to be used by crypto
      subsystem. The system shared keventd_wq is not suitable for
      encryption/decryption, because of potential starvation problem.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      25c38d3f
  4. 18 2月, 2009 16 次提交
  5. 17 2月, 2009 1 次提交
    • H
      crypto: lrw - Fix big endian support · 8eb2dfac
      Herbert Xu 提交于
      It turns out that LRW has never worked properly on big endian.
      This was never discussed because nobody actually used it that
      way.  In fact, it was only discovered when Geert Uytterhoeven
      loaded it through tcrypt which failed the test on it.
      
      The fix is straightforward, on big endian the to find the nth
      bit we should be grouping them by words instead of bytes.  So
      setbit128_bbe should xor with 128 - BITS_PER_LONG instead of
      128 - BITS_PER_BYTE == 0x78.
      Tested-by: NGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      8eb2dfac
  6. 14 2月, 2009 3 次提交
  7. 13 2月, 2009 15 次提交