linux-kernel - Re: Re: 2.6.24 Kernel Soft Lock Up with heavy I/O in dm-crypt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:  <fqcjj9$5bv$1@ger.gmane.org>
Date:	Sat, 01 Mar 2008 22:59:33 +0100
From:	Gunter Ohrner <G.Ohrner@...t.rwth-aachen.de>
To:	linux-kernel@...r.kernel.org
Cc:	dm-devel@...hat.com, linux-kernel@...r.kernel.org
Subject:  Re: Re: 2.6.24 Kernel Soft Lock Up with heavy I/O in	dm-crypt

Milan Broz wrote:
> (the same patch for 2.6.24)

Observations using this patch:

* I did not get a Soft Lockup during my tests so far.

* The latency problems I experienced when writing massive amounts of data to
  an encrypted partitions are improved, though not solved. Using the "dd
  if=/dev/zero of=test.null bs=4M count=1024 ; rm test.null" approach
  mentioned in the other thread, the system stays more responsive and even
  listening to music works more or less, although there are still audible
  interruptions. A few times during the write, CPU usage will spike and IO
  (including music playing in Amarok) will stall for about 0.5 seconds or a
  second.

* This patch seems to hurt performance, I got much lower thoughput and the
  system was never fully loaded, ie. gkrellm showed both cores to run
  between 10% and 40% with a combined CPU utilization fo 30% most of the
  time.
  I got unstable timings from my dd command, but targetting the reiserfs
  partition I got around 18 MB/sec and 34 MB/sec instead of the 41 MB/sec I
  achieved in my tests yesterday.
  So this looks like a viable work around if it reliably avoids the Soft
  Lockup, but it does not seem to be a perfect solution.
  (Addendum: I just got 41 MB/sec with this patch, with an otherwise nearly
  idle system, ie. lots of active processes but none doing anything serious.
  The numbers before applying the patch were much more stable and generally
  higher. Now simply playing or not playing an OGG seems to make the
  difference between 40 MB/sec and 30 MB/sec.)

Greetings,

  Gunter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/