[Bug 9729] New: ondemand cpufreq governor doesn't see when kcryptd/dm-crypt is busy

[Bug 9729] New: ondemand cpufreq governor doesn't see when kcryptd/dm-crypt is busy

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=9729

           Summary: ondemand cpufreq governor doesn't see when kcryptd/dm-
                    crypt is busy
           Product: Power Management
           Version: 2.5
     KernelVersion: 2.6.23.11
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: cpufreq
        AssignedTo: cpufreq@www.linux.org.uk
        ReportedBy: tch@wpkg.org


Distribution: Debian Etch

Problem Description:

It seems that ondemand cpufreq governor doesn't see when CPU is busy with
kcryptd/dm-crypt.

With ondemand cpufreq governor reads/writes from a dm-crypt device will be very
slow.


Steps to reproduce

First, let's use "ondemand" governor - reads will be only about ~8 MB/s.

# echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# cat /proc/cpuinfo | grep MHz
cpu MHz         : 349.991
cpu MHz         : 349.991


# echo 3 > /proc/sys/vm/drop_caches

# dd if=/dev/san2_data/test of=/dev/null bs=64k count=1000
1000+0 records in
1000+0 records out
65536000 bytes (66 MB) copied, 8.64089 seconds, 7.6 MB/s



Now, let's use performance governor - we get almost 60 MB/s:

# echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# cat /proc/cpuinfo | grep MHz
cpu MHz         : 2799.930
cpu MHz         : 2799.930

# echo 3 > /proc/sys/vm/drop_caches

# dd if=/dev/san2_data/test of=/dev/null bs=64k count=1000
1000+0 records in
1000+0 records out
65536000 bytes (66 MB) copied, 1.14821 seconds, 57.1 MB/s



Some system information:


# uname -a
Linux san2 2.6.23.12-pata #10 SMP Fri Dec 21 15:59:53 CET 2007 i686 GNU/Linux


# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Xeon(TM) CPU 2.80GHz
stepping        : 9
cpu MHz         : 349.991
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts sync_rdtsc
cid xtpr
bogomips        : 5585.42
clflush size    : 64

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Xeon(TM) CPU 2.80GHz
stepping        : 9
cpu MHz         : 349.991
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts sync_rdtsc
cid xtpr
bogomips        : 5582.16
clflush size    : 64


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 9729] ondemand cpufreq governor doesn't see when kcryptd/dm-crypt is busy

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=9729


tch@wpkg.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |REJECTED
         Resolution|                            |UNREPRODUCIBLE




------- Comment #1 from tch@wpkg.org  2008-01-16 02:08 -------
After a reboot, I can't reproduce it anymore.

Previously, it was reproducible almost always.

Strange, but that's good, isn't it?

Will reopen if it happens again.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 9729] ondemand cpufreq governor doesn't see when kcryptd/dm-crypt is busy

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=9729


tch@wpkg.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REJECTED                    |REOPENED
         Resolution|UNREPRODUCIBLE              |




------- Comment #2 from tch@wpkg.org  2008-01-18 05:57 -------
Reproduced on yet another machine running 2.6.23.14, using p4-clockmod (max
speed is 1500 MHz):

# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : Intel(R) Celeron(R) M processor         1.50GHz
stepping        : 8
cpu MHz         : 187.500
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx bts
bogomips        : 2996.24
clflush size    : 64


# dd if=/dev/mapper/megathecus_crypt of=/dev/null bs=64k count=10000
10000+0 records in
10000+0 records out
655360000 bytes (655 MB) copied, 100.875 seconds, 6.5 MB/s


For the whole test (100 seconds) CPU was almost 100% busy and was always at the
lowest frequency.


Just start "cat /dev/zero | bzip2 >/dev/null" for a second or two, and CPU will
scale up to 1500 MHz and stay there until dd ends.


Starting another dd about ~10 seconds after a previous dd (if running at 1500
MHz, triggered by bzip2) will scale the CPU to full.


Starting another dd about ~30 seconds or more after a previous dd (if running
at 1500 MHz, triggered by bzip2) will *not* scale the CPU up.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 9729] ondemand cpufreq governor doesn't see when kcryptd/dm-crypt is busy

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=9729


tch@wpkg.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |REJECTED
         Resolution|                            |INVALID




------- Comment #3 from tch@wpkg.org  2008-01-18 14:42 -------
This indeed must be some kind of dm-crypt/kcryptd "feature" and/or some
confusion on how to read CPU usage.

While reading from that dm-crypt device, the following CPU usage was shown (the
numbers are consistent across a few tests):

187 MHz -> ~75% system CPU time in top
375 MHz -> ~66% system CPU time in top
562 MHz -> ~94% system CPU time in top
750 MHz -> ~85% system CPU time in top
937 MHz -> ~85% system CPU time in top
1125 MHz -> ~83% system CPU time in top
1312 MHz -> ~70% system CPU time in top
1500 MHz -> ~70% system CPU time in top


Looks like dm-crypt won't eat the whole CPU power for some reason.

With default 80 as up_threshold for "ondemand" governor, no wonder the
frequency didn't scale up.

So a "fix" for this bug is a matter of lowering up_threshold.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.