WARNING: CPU: 0 PID: 61 at kernel/sched/core.c:7312 __might_sleep()
by Fengguang Wu
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/wait
commit 245747099820df3007f60128b1264fef9d2a69d2
Author: Peter Zijlstra <peterz(a)infradead.org>
AuthorDate: Wed Sep 24 10:18:55 2014 +0200
Commit: Peter Zijlstra <peterz(a)infradead.org>
CommitDate: Mon Oct 27 10:42:51 2014 +0100
sched: Debug nested sleeps
Validate we call might_sleep() with TASK_RUNNING, which catches places
where we nest blocking primitives, eg. mutex usage in a wait loop.
Since all blocking is arranged through task_struct::state, nesting
this will cause the inner primitive to set TASK_RUNNING and the outer
will thus not block.
Another observed problem is calling a blocking function from
schedule()->sched_submit_work()->blk_schedule_flush_plug() which will
then destroy the task state for the actual __schedule() call that
comes after it.
Cc: torvalds(a)linux-foundation.org
Cc: tglx(a)linutronix.de
Cc: ilya.dryomov(a)inktank.com
Cc: umgwanakikbuti(a)gmail.com
Cc: mingo(a)kernel.org
Cc: oleg(a)redhat.com
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Link: http://lkml.kernel.org/r/20140924082242.591637616@infradead.org
===================================================
PARENT COMMIT NOT CLEAN. LOOK OUT FOR WRONG BISECT!
===================================================
120 /kernel/i386-randconfig-r2-1027/592ed717ef33150f6888c333c28021283cc9aabc
To bisect errors in parent:
/c/kernel-tests/queue-reproduce /kernel/i386-randconfig-r2-1027/592ed717ef33150f6888c333c28021283cc9aabc/dmesg-quantal-kbuild-20:20141027231410:i386-randconfig-r2-1027:3.18.0-rc2-00036-g592ed71:139 BUG: kernel test crashed
Attached dmesg for the parent commit, too, to help confirm whether it is a noise error.
+---------------------------------------------------+------------+------------+------------+
| | 592ed717ef | 2457470998 | 2d55520314 |
+---------------------------------------------------+------------+------------+------------+
| boot_successes | 1080 | 267 | 110 |
| boot_failures | 120 | 33 | 21 |
| BUG:kernel_test_crashed | 110 | 30 | 16 |
| WARNING:at_kernel/locking/lockdep.c:check_flags() | 10 | 0 | 3 |
| backtrace:might_fault | 2 | | |
| backtrace:SyS_perf_event_open | 3 | 0 | 1 |
| backtrace:mutex_lock_nested | 1 | | |
| WARNING:at_kernel/sched/core.c:__might_sleep() | 0 | 3 | 2 |
| backtrace:cleanup_net | 0 | 3 | 2 |
| backtrace:register_perf_hw_breakpoint | 0 | 0 | 1 |
| backtrace:hw_breakpoint_event_init | 0 | 0 | 1 |
| backtrace:perf_init_event | 0 | 0 | 1 |
| backtrace:perf_event_alloc | 0 | 0 | 1 |
+---------------------------------------------------+------------+------------+------------+
[ 122.133640] Fix your initscripts?
[ 122.133905] trinity-c0 (23733) uses deprecated remap_file_pages() syscall. See Documentation/vm/remap_file_pages.txt.
[ 122.247299] ------------[ cut here ]------------
[ 122.247328] WARNING: CPU: 0 PID: 61 at kernel/sched/core.c:7312 __might_sleep+0x50/0x249()
[ 122.247334] do not call blocking ops when !TASK_RUNNING; state=2 set at [<c106ffd9>] prepare_to_wait+0x3c/0x5f
[ 122.247339] Modules linked in:
[ 122.247349] CPU: 0 PID: 61 Comm: kworker/u2:1 Not tainted 3.18.0-rc2-00037-g24574709 #136
[ 122.247350] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 122.247368] Workqueue: netns cleanup_net
[ 122.247377] c1071d83 d2b83dd8 d2b83dac c15887b1 d2b83dc8 c104c4c6 00001c90 c1068ebf
[ 122.247383] 00000000 c17b67e3 0000026d d2b83de0 c104c508 00000009 d2b83dd8 c17b5d4b
[ 122.247388] d2b83df4 d2b83e0c c1068ebf c17b5cec 00001c90 c17b5d4b 00000002 c106ffd9
[ 122.247389] Call Trace:
[ 122.247393] [<c1071d83>] ? down_trylock+0x23/0x2c
[ 122.247402] [<c15887b1>] dump_stack+0x16/0x18
[ 122.247413] [<c104c4c6>] warn_slowpath_common+0x66/0x7d
[ 122.247416] [<c1068ebf>] ? __might_sleep+0x50/0x249
[ 122.247419] [<c104c508>] warn_slowpath_fmt+0x2b/0x2f
[ 122.247422] [<c1068ebf>] __might_sleep+0x50/0x249
[ 122.247424] [<c106ffd9>] ? prepare_to_wait+0x3c/0x5f
[ 122.247426] [<c106ffd9>] ? prepare_to_wait+0x3c/0x5f
[ 122.247432] [<c158c364>] mutex_lock_nested+0x23/0x347
[ 122.247436] [<c1075105>] ? trace_hardirqs_on+0xb/0xd
[ 122.247439] [<c158eb0c>] ? _raw_spin_unlock_irqrestore+0x66/0x78
[ 122.247445] [<c1570e10>] rtnl_lock+0x14/0x16
[ 122.247449] [<c156516b>] default_device_exit_batch+0x54/0xf3
[ 122.247452] [<c1570e1f>] ? rtnl_unlock+0xd/0xf
[ 122.247454] [<c1070233>] ? __wake_up_sync+0x12/0x12
[ 122.247461] [<c155e35d>] ops_exit_list+0x20/0x40
[ 122.247464] [<c155ec96>] cleanup_net+0xbe/0x140
[ 122.247473] [<c105ffe4>] process_one_work+0x29e/0x643
[ 122.247479] [<c1061215>] worker_thread+0x23a/0x311
[ 122.247482] [<c1060fdb>] ? rescuer_thread+0x204/0x204
[ 122.247486] [<c10648cc>] kthread+0xbe/0xc3
[ 122.247490] [<c158f4c0>] ret_from_kernel_thread+0x20/0x30
[ 122.247492] [<c106480e>] ? kthread_stop+0x364/0x364
[ 122.247495] ---[ end trace 2073c37ae3c8b3b4 ]---
[ 157.390879] Unregister pv shared memory for cpu 0
git bisect start 2d55520314eb5603b855ac1b994705dc6a352d9e 522e980064c24d3dd9859e9375e17417496567cf --
git bisect good c3f9b6ec744e12ff09677c4c0cb3164ad5b62702 # 19:25 300+ 36 Merge branch 'sched/core'
git bisect good 344c57c17c7f857f9c92317e0d5cbb5c59f8d6e0 # 19:49 300+ 62 Merge branch 'perf/urgent'
git bisect good 54de76b06a8098c11f15857a57e23c6e630a34b6 # 20:19 300+ 66 Merge branch 'perf/core'
git bisect good 126b6dbcbedb5c0defe5c39e0310feed061569bf # 20:51 300+ 50 exit: Deal with nested sleeps
git bisect good 8641f9cba8ce5f3bfc5da47861180617cbfc6e7f # 22:02 300+ 68 module: Fix nested sleep
git bisect bad 245747099820df3007f60128b1264fef9d2a69d2 # 22:25 142- 18 sched: Debug nested sleeps
git bisect good 592ed717ef33150f6888c333c28021283cc9aabc # 22:59 300+ 27 net: Clean up sk_wait_event() vs might_sleep()
# first bad commit: [245747099820df3007f60128b1264fef9d2a69d2] sched: Debug nested sleeps
git bisect good 592ed717ef33150f6888c333c28021283cc9aabc # 00:15 900+ 120 net: Clean up sk_wait_event() vs might_sleep()
git bisect bad 2d55520314eb5603b855ac1b994705dc6a352d9e # 00:19 0- 21 Merge branch 'sched/wait'
git bisect good cac7f2429872d3733dc3f9915857b1691da2eb2f # 01:33 900+ 66 Linux 3.18-rc2
git bisect good 7a891e6323e963f3301e44bdeee734028e34d390 # 02:26 900+ 93 Add linux-next specific files for 20141027
This script may reproduce the error.
----------------------------------------------------------------------------
#!/bin/bash
kernel=$1
initrd=yocto-minimal-i386.cgz
wget --no-clobber https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd
kvm=(
qemu-system-x86_64
-cpu kvm64
-enable-kvm
-kernel $kernel
-initrd $initrd
-m 320
-smp 1
-net nic,vlan=1,model=e1000
-net user,vlan=1
-boot order=nc
-no-reboot
-watchdog i6300esb
-rtc base=localtime
-serial stdio
-display none
-monitor null
)
append=(
hung_task_panic=1
earlyprintk=ttyS0,115200
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
console=ttyS0,115200
console=tty0
vga=normal
root=/dev/ram0
rw
drbd.minor_count=8
)
"${kvm[@]}" --append "${append[*]}"
----------------------------------------------------------------------------
Thanks,
Fengguang
_______________________________________________
LKP mailing list
LKP(a)linux.intel.com
5 years
[PATCH] drm/radeon: Try to init amdkfd only if 64 bit kernel
by Oded Gabbay
amdkfd driver can be compiled only in 64-bit kernel. Therefore, there is no
point in trying to initialize amdkfd in 32-bit kernel.
In addition, in case of specific configuration of 32-bit kernel, no modules and
random kernel base, the symbol_request function doesn't work as expected - It
doesn't return NULL if the symbol doesn't exists. That makes the kernel panic.
Therefore, the as amdkfd doesn't compile in 32-bit kernel, the best way is just
to return false immediately.
Signed-off-by: Oded Gabbay <oded.gabbay(a)amd.com>
---
drivers/gpu/drm/radeon/radeon_kfd.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c b/drivers/gpu/drm/radeon/radeon_kfd.c
index 242fd8b..cb77e5c 100644
--- a/drivers/gpu/drm/radeon/radeon_kfd.c
+++ b/drivers/gpu/drm/radeon/radeon_kfd.c
@@ -101,6 +101,7 @@ static const struct kgd2kfd_calls *kgd2kfd;
bool radeon_kfd_init(void)
{
+#ifdef CONFIG_X86_64
bool (*kgd2kfd_init_p)(unsigned, const struct kfd2kgd_calls*,
const struct kgd2kfd_calls**);
@@ -117,6 +118,9 @@ bool radeon_kfd_init(void)
}
return true;
+#else
+ return false;
+#endif
}
void radeon_kfd_fini(void)
--
1.9.1
5 years
[sb_edac] 50d1bb93672: EDAC sbridge: ECC is disabled. Aborting
by Huang Ying
FYI, we noticed the below changes on
commit 50d1bb93672fa2f42cec6e06ce799fbe864f57e9 ("sb_edac: add support for Haswell based systems")
Something new in kernel log. This may be expected. Just FYI.
[ 12.490615] EDAC sbridge: Seeking for: PCI ID 8086:2fa0
[ 12.491031] EDAC sbridge: Seeking for: PCI ID 8086:2fa0
[ 12.491454] EDAC sbridge: Seeking for: PCI ID 8086:2ffc
[ 12.491865] EDAC sbridge: Seeking for: PCI ID 8086:2ffc
[ 12.492284] EDAC sbridge: Seeking for: PCI ID 8086:2ffd
[ 12.492698] EDAC sbridge: Seeking for: PCI ID 8086:2ffd
[ 12.493110] EDAC sbridge: Seeking for: PCI ID 8086:2f60
[ 12.493528] EDAC sbridge: Seeking for: PCI ID 8086:2fa8
[ 12.493943] EDAC sbridge: Seeking for: PCI ID 8086:2fa8
[ 12.494359] EDAC sbridge: Seeking for: PCI ID 8086:2f71
[ 12.494789] EDAC sbridge: Seeking for: PCI ID 8086:2f71
[ 12.495206] EDAC sbridge: Seeking for: PCI ID 8086:2faa
[ 12.495622] EDAC sbridge: Seeking for: PCI ID 8086:2faa
[ 12.496040] EDAC sbridge: Seeking for: PCI ID 8086:2fab
[ 12.496462] EDAC sbridge: Seeking for: PCI ID 8086:2fab
[ 12.496878] EDAC sbridge: Seeking for: PCI ID 8086:2fac
[ 12.497297] EDAC sbridge: Seeking for: PCI ID 8086:2fac
[ 12.497714] EDAC sbridge: Seeking for: PCI ID 8086:2fad
[ 12.497923] IOAPIC[0]: Set routing entry (8-22 -> 0xb3 -> IRQ 22 Mode:1 Active:1 Dest:1)
[ 12.497927] IOAPIC[0]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:1 Avail:0 Vector:B3 Dest:00000001 SID:F0FF SQ:0 SVT:1)
[ 12.497981] snd_hda_intel 0000:00:1b.0: irq 75 for MSI/MSI-X
[ 12.498086] IOAPIC[1]: Set routing entry (9-12 -> 0xe3 -> IRQ 36 Mode:1 Active:1 Dest:1)
[ 12.498089] IOAPIC[1]: Set IRTE entry (P:1 FPD:0 Dst_Mode:1 Redir_hint:1 Trig_Mode:0 Dlvry_Mode:1 Avail:0 Vector:E3 Dest:00000001 SID:002C SQ:0 SVT:1)
[ 12.498093] snd_hda_intel 0000:02:00.1: Disabling MSI
[ 12.498109] snd_hda_intel 0000:02:00.1: Handle VGA-switcheroo audio client
[ 12.502542] EDAC sbridge: Seeking for: PCI ID 8086:2fad
[ 12.502956] EDAC sbridge: Seeking for: PCI ID 8086:2fbd
[ 12.503365] EDAC sbridge: Seeking for: PCI ID 8086:2f68
[ 12.503781] EDAC sbridge: Seeking for: PCI ID 8086:2f68
[ 12.504197] EDAC sbridge: Seeking for: PCI ID 8086:2f79
[ 12.504620] EDAC sbridge: Seeking for: PCI ID 8086:2f6a
[ 12.505041] EDAC sbridge: Seeking for: PCI ID 8086:2f6b
[ 12.505452] EDAC sbridge: Seeking for: PCI ID 8086:2f6c
[ 12.505869] EDAC sbridge: Seeking for: PCI ID 8086:2f6d
[ 12.506298] EDAC sbridge: ECC is disabled. Aborting
[ 12.506718] EDAC sbridge: Couldn't find mci handler
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Huang, Ying
_______________________________________________
LKP mailing list
LKP(a)linux.intel.com
5 years, 1 month
[sched] a15b12ac36a: -46.9% time.voluntary_context_switches +1.5% will-it-scale.per_process_ops
by Huang Ying
FYI, we noticed the below changes on
commit a15b12ac36ad4e7b856a4ae54937ae26a51aebad ("sched: Do not stop cpu in set_cpus_allowed_ptr() if task is not running")
testbox/testcase/testparams: lkp-g5/will-it-scale/performance-lock1
1ba93d42727c4400 a15b12ac36ad4e7b856a4ae549
---------------- --------------------------
%stddev %change %stddev
\ | \
1517261 ± 0% +1.5% 1539994 ± 0% will-it-scale.per_process_ops
247 ± 30% +131.8% 573 ± 49% sched_debug.cpu#61.ttwu_count
225 ± 22% +142.8% 546 ± 34% sched_debug.cpu#81.ttwu_local
15115 ± 44% +37.3% 20746 ± 40% numa-meminfo.node7.Active
1028 ± 38% +115.3% 2214 ± 36% sched_debug.cpu#16.ttwu_local
2 ± 19% +133.3% 5 ± 43% sched_debug.cpu#89.cpu_load[3]
21 ± 45% +88.2% 40 ± 23% sched_debug.cfs_rq[99]:/.tg_load_contrib
414 ± 33% +98.6% 823 ± 28% sched_debug.cpu#81.ttwu_count
4 ± 10% +88.2% 8 ± 12% sched_debug.cfs_rq[33]:/.runnable_load_avg
22 ± 26% +80.9% 40 ± 24% sched_debug.cfs_rq[103]:/.tg_load_contrib
7 ± 17% -41.4% 4 ± 25% sched_debug.cfs_rq[41]:/.load
7 ± 17% -37.9% 4 ± 19% sched_debug.cpu#41.load
3 ± 22% +106.7% 7 ± 10% sched_debug.cfs_rq[36]:/.runnable_load_avg
174 ± 13% +48.7% 259 ± 31% sched_debug.cpu#112.ttwu_count
4 ± 19% +88.9% 8 ± 5% sched_debug.cfs_rq[35]:/.runnable_load_avg
260 ± 10% +55.6% 405 ± 26% numa-vmstat.node3.nr_anon_pages
1042 ± 10% +56.0% 1626 ± 26% numa-meminfo.node3.AnonPages
26 ± 22% +74.3% 45 ± 16% sched_debug.cfs_rq[65]:/.tg_load_contrib
21 ± 43% +71.3% 37 ± 26% sched_debug.cfs_rq[100]:/.tg_load_contrib
3686 ± 21% +40.2% 5167 ± 19% sched_debug.cpu#16.ttwu_count
142 ± 9% +34.4% 191 ± 24% sched_debug.cpu#112.ttwu_local
5 ± 18% +69.6% 9 ± 15% sched_debug.cfs_rq[35]:/.load
2 ± 30% +100.0% 5 ± 37% sched_debug.cpu#106.cpu_load[1]
3 ± 23% +100.0% 6 ± 48% sched_debug.cpu#106.cpu_load[2]
5 ± 18% +69.6% 9 ± 15% sched_debug.cpu#35.load
9 ± 20% +48.6% 13 ± 16% sched_debug.cfs_rq[7]:/.runnable_load_avg
1727 ± 15% +43.9% 2484 ± 30% sched_debug.cpu#34.ttwu_local
10 ± 17% -40.5% 6 ± 13% sched_debug.cpu#41.cpu_load[0]
10 ± 14% -29.3% 7 ± 5% sched_debug.cpu#45.cpu_load[4]
10 ± 17% -33.3% 7 ± 10% sched_debug.cpu#41.cpu_load[1]
6121 ± 8% +56.7% 9595 ± 30% sched_debug.cpu#13.sched_goidle
13 ± 8% -25.9% 10 ± 17% sched_debug.cpu#39.cpu_load[2]
12 ± 16% -24.0% 9 ± 15% sched_debug.cpu#37.cpu_load[2]
492 ± 17% -21.3% 387 ± 24% sched_debug.cpu#46.ttwu_count
3761 ± 11% -23.9% 2863 ± 15% sched_debug.cpu#93.curr->pid
570 ± 19% +43.2% 816 ± 17% sched_debug.cpu#86.ttwu_count
5279 ± 8% +63.5% 8631 ± 33% sched_debug.cpu#13.ttwu_count
377 ± 22% -28.6% 269 ± 14% sched_debug.cpu#46.ttwu_local
5396 ± 10% +29.9% 7007 ± 14% sched_debug.cpu#16.sched_goidle
1959 ± 12% +36.9% 2683 ± 15% numa-vmstat.node2.nr_slab_reclaimable
7839 ± 12% +37.0% 10736 ± 15% numa-meminfo.node2.SReclaimable
5 ± 15% +66.7% 8 ± 9% sched_debug.cfs_rq[33]:/.load
5 ± 25% +47.8% 8 ± 10% sched_debug.cfs_rq[37]:/.load
2 ± 0% +87.5% 3 ± 34% sched_debug.cpu#89.cpu_load[4]
5 ± 15% +66.7% 8 ± 9% sched_debug.cpu#33.load
6 ± 23% +41.7% 8 ± 10% sched_debug.cpu#37.load
8 ± 10% -26.5% 6 ± 6% sched_debug.cpu#51.cpu_load[1]
7300 ± 37% +63.6% 11943 ± 16% softirqs.TASKLET
2984 ± 6% +43.1% 4271 ± 23% sched_debug.cpu#20.ttwu_count
328 ± 4% +40.5% 462 ± 25% sched_debug.cpu#26.ttwu_local
10 ± 7% -27.5% 7 ± 5% sched_debug.cpu#43.cpu_load[3]
9 ± 8% -30.8% 6 ± 6% sched_debug.cpu#41.cpu_load[3]
9 ± 8% -27.0% 6 ± 6% sched_debug.cpu#41.cpu_load[4]
10 ± 14% -32.5% 6 ± 6% sched_debug.cpu#41.cpu_load[2]
16292 ± 6% +42.8% 23260 ± 25% sched_debug.cpu#13.nr_switches
14 ± 28% +55.9% 23 ± 8% sched_debug.cpu#99.cpu_load[0]
5 ± 8% +28.6% 6 ± 12% sched_debug.cpu#17.load
13 ± 7% -23.1% 10 ± 12% sched_debug.cpu#39.cpu_load[3]
7 ± 10% -35.7% 4 ± 11% sched_debug.cfs_rq[45]:/.runnable_load_avg
5076 ± 13% -21.8% 3970 ± 11% numa-vmstat.node0.nr_slab_unreclaimable
20306 ± 13% -21.8% 15886 ± 11% numa-meminfo.node0.SUnreclaim
10 ± 10% -28.6% 7 ± 6% sched_debug.cpu#45.cpu_load[3]
11 ± 11% -29.5% 7 ± 14% sched_debug.cpu#45.cpu_load[1]
10 ± 12% -26.8% 7 ± 6% sched_debug.cpu#44.cpu_load[1]
10 ± 10% -28.6% 7 ± 6% sched_debug.cpu#44.cpu_load[0]
7 ± 17% +48.3% 10 ± 7% sched_debug.cfs_rq[11]:/.runnable_load_avg
11 ± 12% -34.1% 7 ± 11% sched_debug.cpu#47.cpu_load[0]
10 ± 10% -27.9% 7 ± 5% sched_debug.cpu#47.cpu_load[1]
10 ± 8% -26.8% 7 ± 11% sched_debug.cpu#47.cpu_load[2]
10 ± 8% -28.6% 7 ± 14% sched_debug.cpu#43.cpu_load[0]
10 ± 10% -27.9% 7 ± 10% sched_debug.cpu#43.cpu_load[1]
10 ± 10% -28.6% 7 ± 6% sched_debug.cpu#43.cpu_load[2]
12940 ± 3% +49.8% 19387 ± 35% numa-meminfo.node2.Active(anon)
3235 ± 2% +49.8% 4844 ± 35% numa-vmstat.node2.nr_active_anon
17 ± 17% +36.6% 24 ± 9% sched_debug.cpu#97.cpu_load[2]
14725 ± 8% +21.8% 17928 ± 11% sched_debug.cpu#16.nr_switches
667 ± 10% +45.3% 969 ± 22% sched_debug.cpu#17.ttwu_local
3257 ± 5% +22.4% 3988 ± 11% sched_debug.cpu#118.curr->pid
3144 ± 15% -20.7% 2493 ± 8% sched_debug.cpu#95.curr->pid
2192 ± 11% +50.9% 3308 ± 37% sched_debug.cpu#18.ttwu_count
6 ± 11% +37.5% 8 ± 19% sched_debug.cfs_rq[22]:/.load
12 ± 5% +27.1% 15 ± 8% sched_debug.cpu#5.cpu_load[1]
11 ± 12% -23.4% 9 ± 13% sched_debug.cpu#37.cpu_load[3]
6 ± 11% +37.5% 8 ± 19% sched_debug.cpu#22.load
8 ± 8% -25.0% 6 ± 0% sched_debug.cpu#51.cpu_load[2]
7 ± 6% -20.0% 6 ± 11% sched_debug.cpu#55.cpu_load[3]
11 ± 9% -17.4% 9 ± 9% sched_debug.cpu#39.cpu_load[4]
12 ± 5% -22.9% 9 ± 11% sched_debug.cpu#38.cpu_load[3]
420 ± 13% +43.0% 601 ± 9% sched_debug.cpu#30.ttwu_local
1682 ± 14% +38.5% 2329 ± 17% numa-meminfo.node7.AnonPages
423 ± 13% +37.0% 579 ± 16% numa-vmstat.node7.nr_anon_pages
15 ± 13% +41.9% 22 ± 5% sched_debug.cpu#99.cpu_load[1]
6 ± 20% +44.0% 9 ± 13% sched_debug.cfs_rq[19]:/.runnable_load_avg
9 ± 4% -24.3% 7 ± 0% sched_debug.cpu#43.cpu_load[4]
6341 ± 7% -19.6% 5100 ± 16% sched_debug.cpu#43.curr->pid
2577 ± 11% -11.9% 2270 ± 10% sched_debug.cpu#33.ttwu_count
13 ± 6% -18.5% 11 ± 12% sched_debug.cpu#40.cpu_load[2]
4828 ± 6% +23.8% 5979 ± 6% sched_debug.cpu#34.curr->pid
4351 ± 12% +33.9% 5824 ± 12% sched_debug.cpu#36.curr->pid
10 ± 8% -23.8% 8 ± 8% sched_debug.cpu#37.cpu_load[4]
10 ± 14% -28.6% 7 ± 6% sched_debug.cpu#45.cpu_load[2]
17 ± 22% +40.6% 24 ± 7% sched_debug.cpu#97.cpu_load[1]
11 ± 9% +21.3% 14 ± 5% sched_debug.cpu#7.cpu_load[2]
10 ± 8% -26.2% 7 ± 10% sched_debug.cpu#36.cpu_load[4]
12853 ± 2% +20.0% 15429 ± 11% numa-meminfo.node2.AnonPages
4744 ± 8% +30.8% 6204 ± 11% sched_debug.cpu#35.curr->pid
3214 ± 2% +20.0% 3856 ± 11% numa-vmstat.node2.nr_anon_pages
6181 ± 6% +24.9% 7718 ± 9% sched_debug.cpu#13.curr->pid
6675 ± 23% +27.5% 8510 ± 10% sched_debug.cfs_rq[91]:/.tg_load_avg
171261 ± 5% -22.2% 133177 ± 15% numa-numastat.node0.local_node
6589 ± 21% +29.3% 8522 ± 11% sched_debug.cfs_rq[89]:/.tg_load_avg
6508 ± 20% +28.0% 8331 ± 8% sched_debug.cfs_rq[88]:/.tg_load_avg
6598 ± 22% +29.2% 8525 ± 11% sched_debug.cfs_rq[90]:/.tg_load_avg
590 ± 13% -21.4% 464 ± 7% sched_debug.cpu#105.ttwu_local
175392 ± 5% -21.7% 137308 ± 14% numa-numastat.node0.numa_hit
11 ± 6% -18.2% 9 ± 7% sched_debug.cpu#38.cpu_load[4]
6643 ± 23% +27.4% 8465 ± 10% sched_debug.cfs_rq[94]:/.tg_load_avg
6764 ± 7% +13.8% 7695 ± 7% sched_debug.cpu#12.curr->pid
29 ± 28% +34.5% 39 ± 5% sched_debug.cfs_rq[98]:/.tg_load_contrib
1776 ± 7% +29.4% 2298 ± 13% sched_debug.cpu#11.ttwu_local
13 ± 0% -19.2% 10 ± 8% sched_debug.cpu#40.cpu_load[3]
7 ± 5% -17.2% 6 ± 0% sched_debug.cpu#51.cpu_load[3]
7371 ± 20% -18.0% 6045 ± 3% sched_debug.cpu#1.sched_goidle
26560 ± 2% +14.0% 30287 ± 7% numa-meminfo.node2.Slab
16161 ± 6% -9.4% 14646 ± 1% sched_debug.cfs_rq[27]:/.avg->runnable_avg_sum
351 ± 6% -9.3% 318 ± 1% sched_debug.cfs_rq[27]:/.tg_runnable_contrib
7753 ± 27% -22.9% 5976 ± 5% sched_debug.cpu#2.sched_goidle
3828 ± 9% +17.3% 4490 ± 6% sched_debug.cpu#23.sched_goidle
23925 ± 2% +23.0% 29419 ± 23% numa-meminfo.node2.Active
47 ± 6% -15.8% 40 ± 19% sched_debug.cpu#42.cpu_load[1]
282 ± 5% -9.7% 254 ± 7% sched_debug.cfs_rq[109]:/.tg_runnable_contrib
349 ± 5% -9.3% 317 ± 1% sched_debug.cfs_rq[26]:/.tg_runnable_contrib
6941 ± 3% +8.9% 7558 ± 7% sched_debug.cpu#61.nr_switches
16051 ± 5% -8.9% 14618 ± 1% sched_debug.cfs_rq[26]:/.avg->runnable_avg_sum
238944 ± 3% +9.2% 260958 ± 5% numa-vmstat.node2.numa_local
12966 ± 5% -9.5% 11732 ± 6% sched_debug.cfs_rq[109]:/.avg->runnable_avg_sum
1004 ± 3% +8.2% 1086 ± 4% sched_debug.cpu#118.sched_goidle
20746 ± 4% -8.4% 19000 ± 1% sched_debug.cfs_rq[45]:/.avg->runnable_avg_sum
451 ± 4% -8.3% 413 ± 1% sched_debug.cfs_rq[45]:/.tg_runnable_contrib
3538 ± 4% +17.2% 4147 ± 8% sched_debug.cpu#26.ttwu_count
16 ± 9% +13.8% 18 ± 2% sched_debug.cpu#99.cpu_load[3]
1531 ± 0% +11.3% 1704 ± 1% numa-meminfo.node7.KernelStack
3569 ± 3% +17.2% 4182 ± 10% sched_debug.cpu#24.sched_goidle
1820 ± 3% -12.5% 1594 ± 8% slabinfo.taskstats.num_objs
1819 ± 3% -12.4% 1594 ± 8% slabinfo.taskstats.active_objs
4006 ± 5% +19.1% 4769 ± 8% sched_debug.cpu#17.sched_goidle
21412 ± 19% -17.0% 17779 ± 3% sched_debug.cpu#2.nr_switches
16 ± 9% +24.2% 20 ± 4% sched_debug.cpu#99.cpu_load[2]
10493 ± 7% +13.3% 11890 ± 4% sched_debug.cpu#23.nr_switches
1207 ± 2% -46.9% 640 ± 4% time.voluntary_context_switches
time.voluntary_context_switches
1300 ++-----------*--*--------------------*-------------------------------+
*..*.*..*.. + *.*..*..*.*..*..* .*..*..*. .*..*.*..*.. |
1200 ++ * * *. *.*..*
1100 ++ |
| |
1000 ++ |
| |
900 ++ |
| |
800 ++ |
700 ++ |
O O O O O O O O O O O O O |
600 ++ O O O O O O O O O |
| O |
500 ++-------------------------------------------------------------------+
[*] bisect-good sample
[O] bisect-bad sample
To reproduce:
apt-get install ruby ruby-oj
git clone git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/setup-local job.yaml # the job file attached in this email
bin/run-local job.yaml
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Huang, Ying
_______________________________________________
LKP mailing list
LKP(a)linux.intel.com
5 years, 1 month
Re: [LKP] [PATCH] tick/powerclamp: Remove tick_nohz_idle abuse
by Jacob Pan
>
>
> -----Original Message-----
> From: Preeti U Murthy [mailto:preeti@linux.vnet.ibm.com]
> Sent: Thursday, December 18, 2014 9:28 AM
> To: Thomas Gleixner; Preeti Murthy; Pan, Jacob jun; Peter Zijlstra
> Cc: Viresh Kumar; Frederic Weisbecker; Wu, Fengguang; Frederic
> Weisbecker; LKML; LKP; Zhang, Rui Subject: Re: [PATCH]
> tick/powerclamp: Remove tick_nohz_idle abuse
>
> Hi Thomas,
>
> On 12/18/2014 04:21 PM, Thomas Gleixner wrote:
> > commit 4dbd27711cd9 "tick: export nohz tick idle symbols for module
> > use" was merged via the thermal tree without an explicit ack from
> > the relevant maintainers.
> >
> > The exports are abused by the intel powerclamp driver which
> > implements a fake idle state from a sched FIFO task. This causes
> > all kinds of wreckage in the NOHZ core code which rightfully
> > assumes that tick_nohz_idle_enter/exit() are only called from the
> > idle task itself.
> >
> > Recent changes in the NOHZ core lead to a failure of the powerclamp
> > driver and now people try to hack completely broken and backwards
> > workarounds into the NOHZ core code. This is completely
> > unacceptable.
> >
> > The real solution is to fix the powerclamp driver by rewriting it
> > with a sane concept, but that's beyond the scope of this.
> >
> > So the only solution for now is to remove the calls into the core
> > NOHZ code from the powerclamp trainwreck along with the exports.
> >
> > Fixes: d6d71ee4a14a "PM: Introduce Intel PowerClamp Driver"
> > Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
> > ---
> > diff --git a/drivers/thermal/intel_powerclamp.c
> > b/drivers/thermal/intel_powerclamp.c
> > index b46c706e1cac..e98b4249187c 100644
> > --- a/drivers/thermal/intel_powerclamp.c
> > +++ b/drivers/thermal/intel_powerclamp.c
> > @@ -435,7 +435,6 @@ static int clamp_thread(void *arg)
> > * allowed. thus jiffies are updated properly.
> > */
> > preempt_disable();
> > - tick_nohz_idle_enter();
> > /* mwait until target jiffies is reached */
> > while (time_before(jiffies, target_jiffies)) {
> > unsigned long ecx = 1;
> > @@ -451,7 +450,6 @@ static int clamp_thread(void *arg)
> > start_critical_timings();
> > atomic_inc(&idle_wakeup_counter);
> > }
> > - tick_nohz_idle_exit();
> > preempt_enable();
> > }
> > del_timer_sync(&wakeup_timer);
> > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > index 4d54b7540585..1363d58f07e9 100644
> > --- a/kernel/time/tick-sched.c
> > +++ b/kernel/time/tick-sched.c
> > @@ -847,7 +847,6 @@ void tick_nohz_idle_enter(void)
> >
> > local_irq_enable();
> > }
> > -EXPORT_SYMBOL_GPL(tick_nohz_idle_enter);
> >
> > /**
> > * tick_nohz_irq_exit - update next tick event from interrupt exit
> > @@ -974,7 +973,6 @@ void tick_nohz_idle_exit(void)
> >
> > local_irq_enable();
> > }
> > -EXPORT_SYMBOL_GPL(tick_nohz_idle_exit);
> >
> > static int tick_nohz_reprogram(struct tick_sched *ts, ktime_t
> > now) {
> >
>
(switching to my linux email)
OK I agree, also as I mentioned earlier, Peter already has a patch for
consolidated idle loop and remove tick_nohz_idle_enter/exit call from
powerclamp driver. I have been working on a few tweaks to maintain the
functionality and efficiency with the consolidated idle loop.
We can apply the patches on top of yours.
> Ok the solution looks apt to me.
>
> Let me see if I can come up with a sane solution for powerclamp based
> on the suggestions that you gave in the previous thread. I was
> thinking of the below steps towards its implementation. The idea is
> based on the throttling mechanism that you had suggested.
>
> 1. Queue a deferable periodic timer whose handler checks if idle
> needs to be injected. If so, it sets rq->need_throttle for the cpu.
> If its already in the fake idle period, it clears rq->need_throttle
> and sets need_resched.
>
The key to powerclamp driver is to achieve package level idle
states, which implies synchronized idle injection. From
power/performance standpoint, only package level idle states is worth
injection.
IMHO, percpu the deferrable timer based solution makes it hard to
synchronize. And you have to be able to request deepest idle.
Some background on why we do this:
As the power consumption in package level idle goes lower and lower with
new processors, it became negligible compared to running states.
Therefore, powerclamp driver can give you near linear power-performance
throttling. Idle injection at per cpu core level may not be worthwhile
in most of todays' cpus.
Just some background on the use case, if you want to try powerclamp on
your ultrabook, you will be able compare the effectiveness in
controlling cpu thermal. You can use tmon tool in kernel source.
e.g.
$tools/thermal/tmon$ sudo ./tmon -z 1 -c intel_powerclamp
(choose -z thermal zone of your processor zone, pkg-temp or acpi tz)
> 2. pick_next_task_fair() checks rq->need_throttle and dequeues all
> tasks in the rq if this is set and puts them on a throttled list.
> This mechanism is similar to throttling cfs rq today. This function
> hence fails to return a task, and if no task from any other sched
> class exists, idle task is picked.
>
> Peter thoughts?
>
> 3. So we are now in the idle injected period. The scheduler state is
> sane because the cpu is idle, rq->nr_running = 0, rq->curr =
> rq->idle. The nohz state is sane, because ts->inidle = 1 and
> tick_stopped may or may not be 1 and they are set by an idle task.
>
> 4. When need_resched is set again, the idle task of course unsets
> inidle and restarts tick. In the following scheduler tick,
> pick_next_task_fair() sees that rq->need_throttle is cleared,
> enqueues back the tasks and returns one of them to run.
>
> Of course there may be several points that I have missed. But how
> does the approach appear? If it looks sane enough, the cases which do
> not obviously fall in place can be worked upon.
>
> Regards
> Preeti U Murthy
>
5 years, 1 month
Hi my friend!
by Elena
Hello!!!
My name is Elena.
I looked yours profil and have become interested in you.
I live in Russia in city Cheboksary.
If you have become interested in me.
Write to me at once on mine e-mail: zhibrovarimmma(a)yandex.ru mailto:zhibrovarimmma@yandex.ru
I shall tell to you more about myself also I shall send you my photos.
I wait for yours the letter and a photo.
Elena.
5 years, 1 month
[PATCH v2] drm/radeon: Init amdkfd only if it was compiled
by Oded Gabbay
This patch changes the radeon_kfd_init(), which is used to initialize the
interface between radeon and amdkfd, so the interface will be initialized only
if amdkfd was build, either as module or inside the kernel image.
In the modules case, the symbol_request() will be used (same as old code). In
the in-image compilation case, a direct call to kgd2kfd_init() will be done.
For other cases, radeon_kfd_init() will just return false.
This patch is necessary because in case of the following specific
configuration: kernel 32-bit, no modules support, random kernel base and no
hibernation, the symbol_request() doesn't work as expected - it doesn't return
NULL if the symbol doesn't exists - which makes the kernel panic.
Signed-off-by: Oded Gabbay <oded.gabbay(a)amd.com>
---
drivers/gpu/drm/radeon/radeon_kfd.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c b/drivers/gpu/drm/radeon/radeon_kfd.c
index 242fd8b..d3e78b4 100644
--- a/drivers/gpu/drm/radeon/radeon_kfd.c
+++ b/drivers/gpu/drm/radeon/radeon_kfd.c
@@ -101,6 +101,7 @@ static const struct kgd2kfd_calls *kgd2kfd;
bool radeon_kfd_init(void)
{
+#if defined(CONFIG_HSA_AMD_MODULE)
bool (*kgd2kfd_init_p)(unsigned, const struct kfd2kgd_calls*,
const struct kgd2kfd_calls**);
@@ -117,6 +118,17 @@ bool radeon_kfd_init(void)
}
return true;
+#elif defined(CONFIG_HSA_AMD)
+ if (!kgd2kfd_init(KFD_INTERFACE_VERSION, &kfd2kgd, &kgd2kfd)) {
+ kgd2kfd = NULL;
+
+ return false;
+ }
+
+ return true;
+#else
+ return false;
+#endif
}
void radeon_kfd_fini(void)
--
1.9.1
5 years, 1 month
[sysfs/kernfs] INFO: possible circular locking dependency detected ]
by Huang Ying
FYI, we noticed the below changes on
commit 2b75869bba676c248d8d25ae6d2bd9221dfffdb6 ("sysfs/kernfs: allow attributes to request write buffer be pre-allocated.")
+----------------------------------------------------+------------+------------+
| | 0936896056 | 2b75869bba |
+----------------------------------------------------+------------+------------+
| boot_successes | 64 | 22 |
| boot_failures | 6 | 48 |
| Initramfs_unpacking_failed | 6 | 12 |
| BUG:unable_to_handle_kernel | 6 | 12 |
| Oops | 4 | 9 |
| EIP_is_at_native_set_pte | 4 | 7 |
| Kernel_panic-not_syncing:Fatal_exception | 4 | 7 |
| backtrace:set_memory_np | 4 | 7 |
| backtrace:free_init_pages | 4 | 7 |
| backtrace:populate_rootfs | 4 | 7 |
| backtrace:kernel_init_freeable | 4 | 43 |
| INFO:possible_circular_locking_dependency_detected | 0 | 36 |
| Out_of_memory:Kill_process | 0 | 36 |
| backtrace:vfs_write | 0 | 36 |
| backtrace:SyS_write | 0 | 36 |
| backtrace:cpu_up | 0 | 36 |
| backtrace:smp_init | 0 | 36 |
| backtrace:process_vm_rw | 0 | 17 |
| backtrace:SyS_process_vm_writev | 0 | 7 |
| page_allocation_failure:order:#,mode | 0 | 11 |
| backtrace:SyS_process_vm_readv | 0 | 10 |
| backtrace:do_fork | 0 | 7 |
| backtrace:SyS_clone | 0 | 6 |
| backtrace:vfs_writev | 0 | 6 |
| backtrace:SyS_writev | 0 | 6 |
| backtrace:pgd_alloc | 0 | 3 |
| backtrace:mm_init | 0 | 3 |
| BUG:unable_to | 0 | 1 |
| backtrace:lock_torture_stats | 0 | 1 |
| backtrace:wait_for_helper | 0 | 2 |
| backtrace:__mm_populate | 0 | 1 |
| backtrace:SyS_remap_file_pages | 0 | 1 |
| backtrace:path_listxattr | 0 | 1 |
| backtrace:SyS_listxattr | 0 | 1 |
+----------------------------------------------------+------------+------------+
[ 61.776179] Writes: Total: 4 Max/Min: 0/0 Fail: 0
[ 69.817190]
[ 69.817551] ======================================================
[ 69.818586] [ INFO: possible circular locking dependency detected ]
[ 69.819634] 3.19.0-rc1 #1 Not tainted
[ 69.820091] -------------------------------------------------------
[ 69.820091] trinity-c0/3694 is trying to acquire lock:
[ 69.820091] (cpu_hotplug.lock){++++++}, at: [<84e69793>] get_online_cpus+0x42/0xcc
[ 69.820091]
[ 69.820091] but task is already holding lock:
[ 69.820091] ((oom_notify_list).rwsem){.+.+..}, at: [<84e94e5d>] __blocking_notifier_call_chain+0x36/0x87
[ 69.820091]
[ 69.820091] which lock already depends on the new lock.
[ 69.820091]
[ 69.820091]
[ 69.820091] the existing dependency chain (in reverse order) is:
[ 69.820091]
-> #4 ((oom_notify_list).rwsem){.+.+..}:
[ 69.820091] [<84ec66bd>] lock_acquire+0x9c/0xda
[ 69.820091] [<858c6d5a>] down_read+0x56/0x81
[ 69.820091] [<84e94e5d>] __blocking_notifier_call_chain+0x36/0x87
[ 69.820091] [<84e94ec8>] blocking_notifier_call_chain+0x1a/0x2a
[ 69.820091] [<84f49773>] out_of_memory+0x39/0x55a
[ 69.820091] [<84f50213>] __alloc_pages_nodemask+0x967/0xb2e
[ 69.820091] [<84f62bb4>] shmem_getpage_gfp+0x477/0xa83
[ 69.820091] [<84f63281>] shmem_getpage+0x2d/0x40
[ 69.820091] [<84f641a9>] shmem_fault+0x1e8/0x233
[ 69.820091] [<84f78ae2>] __do_fault+0x37/0x95
[ 69.820091] [<84f7afea>] do_read_fault+0x2bf/0x410
[ 69.820091] [<84f7ba04>] handle_mm_fault+0x23c/0x1556
[ 69.820091] [<84e5c345>] __do_page_fault+0x792/0xbea
[ 69.820091] [<84e5c7ef>] do_page_fault+0x52/0x64
[ 69.820091] [<84e57088>] do_async_page_fault+0x3f/0xe6
[ 69.820091] [<858cadf6>] error_code+0x42/0x48
[ 69.820091] [<84f73dd9>] copy_page_from_iter+0xef/0x34d
[ 69.820091] [<84f92954>] process_vm_rw_core+0x5da/0x7d0
[ 69.820091] [<84f92c81>] process_vm_rw+0x137/0x1c7
[ 69.820091] [<84f92dad>] SyS_process_vm_writev+0x38/0x64
[ 69.820091] [<858ca505>] syscall_after_call+0x0/0x4
[ 69.820091]
-> #3 (&mm->mmap_sem){++++++}:
[ 69.820091] [<84ec66bd>] lock_acquire+0x9c/0xda
[ 69.820091] [<84f786bb>] might_fault+0xb2/0xf0
[ 69.820091] [<850279e2>] kernfs_fop_write+0x13b/0x260
[ 69.820091] [<84fa98bb>] vfs_write+0x101/0x1c4
[ 69.820091] [<84fa9cb9>] SyS_write+0x82/0xf5
[ 69.820091] [<858ca505>] syscall_after_call+0x0/0x4
[ 69.820091]
-> #2 (s_active#7){++++.+}:
[ 69.820091] [<84ec66bd>] lock_acquire+0x9c/0xda
[ 69.820091] [<850248e1>] __kernfs_remove+0x2d4/0x5e0
[ 69.820091] [<85025df9>] kernfs_remove_by_name_ns+0xa5/0xeb
[ 69.820091] [<850287a8>] sysfs_remove_file_ns+0x1b/0x2b
[ 69.820091] [<8561e9b3>] device_remove_file+0x3b/0x59
[ 69.820091] [<8561f9de>] device_del+0x256/0x37b
[ 69.820091] [<8561fb7f>] device_unregister+0x7c/0xaa
[ 69.820091] [<8561fc11>] device_destroy+0x64/0x77
[ 69.820091] [<84e42a76>] msr_device_destroy+0x22/0x32
[ 69.820091] [<84e42ae5>] msr_class_cpu_callback+0x5f/0xab
[ 69.820091] [<84e947ef>] notifier_call_chain+0x91/0xee
[ 69.820091] [<84e94892>] __raw_notifier_call_chain+0x1c/0x2c
[ 69.820091] [<84e699fa>] __cpu_notify+0x23/0x72
[ 69.820091] [<84e69a64>] cpu_notify+0x1b/0x2b
[ 69.820091] [<84e69a8a>] cpu_notify_nofail+0x16/0x48
[ 69.820091] [<858b1296>] _cpu_down+0x37c/0x520
[ 69.820091] [<858b1486>] cpu_down+0x4c/0x75
[ 69.820091] [<85629270>] cpu_subsys_offline+0x1c/0x2c
[ 69.820091] [<8562223d>] device_offline+0xc2/0x129
[ 69.820091] [<8562241b>] online_store+0xa0/0xe5
[ 69.820091] [<8561e528>] dev_attr_store+0x2f/0x4a
[ 69.820091] [<850285ea>] sysfs_kf_write+0x57/0x72
[ 69.820091] [<85027a75>] kernfs_fop_write+0x1ce/0x260
[ 69.820091] [<84fa98bb>] vfs_write+0x101/0x1c4
[ 69.820091] [<84fa9cb9>] SyS_write+0x82/0xf5
[ 69.820091] [<858ca505>] syscall_after_call+0x0/0x4
[ 69.820091]
-> #1 (cpu_hotplug.lock#2){+.+.+.}:
[ 69.820091] [<84ec66bd>] lock_acquire+0x9c/0xda
[ 69.820091] [<858c2327>] mutex_lock_nested+0x82/0x9c7
[ 69.820091] [<84e69cd8>] cpu_hotplug_begin+0x62/0xe3
[ 69.820091] [<84e69e83>] cpu_up+0xd3/0x35f
[ 69.820091] [<85feddfe>] smp_init+0x11a/0x12d
[ 69.820091] [<85fc68f4>] kernel_init_freeable+0x108/0x3f6
[ 69.820091] [<858b0125>] kernel_init+0x16/0x1e7
[ 69.820091] [<858ca341>] ret_from_kernel_thread+0x21/0x30
[ 69.820091]
-> #0 (cpu_hotplug.lock){++++++}:
[ 69.820091] [<84ec5bf0>] __lock_acquire+0x14e7/0x1f18
[ 69.820091] [<84ec66bd>] lock_acquire+0x9c/0xda
[ 69.820091] [<84e697ba>] get_online_cpus+0x69/0xcc
[ 69.820091] [<84ee11c0>] rcu_oom_notify+0xea/0x218
[ 69.820091] [<84e947ef>] notifier_call_chain+0x91/0xee
[ 69.820091] [<84e94e7d>] __blocking_notifier_call_chain+0x56/0x87
[ 69.820091] [<84e94ec8>] blocking_notifier_call_chain+0x1a/0x2a
[ 69.820091] [<84f49773>] out_of_memory+0x39/0x55a
[ 69.820091] [<84f50213>] __alloc_pages_nodemask+0x967/0xb2e
[ 69.820091] [<84f62bb4>] shmem_getpage_gfp+0x477/0xa83
[ 69.820091] [<84f63281>] shmem_getpage+0x2d/0x40
[ 69.820091] [<84f641a9>] shmem_fault+0x1e8/0x233
[ 69.820091] [<84f78ae2>] __do_fault+0x37/0x95
[ 69.820091] [<84f7afea>] do_read_fault+0x2bf/0x410
[ 69.820091] [<84f7ba04>] handle_mm_fault+0x23c/0x1556
[ 69.820091] [<84e5c345>] __do_page_fault+0x792/0xbea
[ 69.820091] [<84e5c7ef>] do_page_fault+0x52/0x64
[ 69.820091] [<84e57088>] do_async_page_fault+0x3f/0xe6
[ 69.820091] [<858cadf6>] error_code+0x42/0x48
[ 69.820091] [<84f73dd9>] copy_page_from_iter+0xef/0x34d
[ 69.820091] [<84f92954>] process_vm_rw_core+0x5da/0x7d0
[ 69.820091] [<84f92c81>] process_vm_rw+0x137/0x1c7
[ 69.820091] [<84f92dad>] SyS_process_vm_writev+0x38/0x64
[ 69.820091] [<858ca505>] syscall_after_call+0x0/0x4
[ 69.820091]
[ 69.820091] other info that might help us debug this:
[ 69.820091]
[ 69.820091] Chain exists of:
cpu_hotplug.lock --> &mm->mmap_sem --> (oom_notify_list).rwsem
[ 69.820091] Possible unsafe locking scenario:
[ 69.820091]
[ 69.820091] CPU0 CPU1
[ 69.820091] ---- ----
[ 69.820091] lock((oom_notify_list).rwsem);
[ 69.820091] lock(&mm->mmap_sem);
[ 69.820091] lock((oom_notify_list).rwsem);
[ 69.820091] lock(cpu_hotplug.lock);
[ 69.820091]
[ 69.820091] *** DEADLOCK ***
[ 69.820091]
[ 69.820091] 2 locks held by trinity-c0/3694:
[ 69.820091] #0: (&mm->mmap_sem){++++++}, at: [<84e5c252>] __do_page_fault+0x69f/0xbea
[ 69.820091] #1: ((oom_notify_list).rwsem){.+.+..}, at: [<84e94e5d>] __blocking_notifier_call_chain+0x36/0x87
[ 69.820091]
[ 69.820091] stack backtrace:
[ 69.820091] CPU: 0 PID: 3694 Comm: trinity-c0 Not tainted 3.19.0-rc1 #1
[ 69.820091] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 69.820091] 00000000 817ef9b4 858b7132 86511480 817ef9e4 84ec0717 85cb3759 85cb3531
[ 69.820091] 85cb34f9 85cb351a 85cb34f9 817efa38 816a09c0 00000002 816a0e60 816a09c0
[ 69.820091] 817efa68 84ec5bf0 816a0e48 fffffff4 ffffffff 86511480 000004b0 00000000
[ 69.820091] Call Trace:
[ 69.820091] [<858b7132>] dump_stack+0xf3/0x192
[ 69.820091] [<84ec0717>] print_circular_bug+0x3cd/0x3e8
[ 69.820091] [<84ec5bf0>] __lock_acquire+0x14e7/0x1f18
[ 69.820091] [<84ec54dc>] ? __lock_acquire+0xdd3/0x1f18
[ 69.820091] [<84ec66bd>] lock_acquire+0x9c/0xda
[ 69.820091] [<84e69793>] ? get_online_cpus+0x42/0xcc
[ 69.820091] [<84e697ba>] get_online_cpus+0x69/0xcc
[ 69.820091] [<84e69793>] ? get_online_cpus+0x42/0xcc
[ 69.820091] [<84ee11c0>] rcu_oom_notify+0xea/0x218
[ 69.820091] [<84ec66e2>] ? lock_acquire+0xc1/0xda
[ 69.820091] [<84e947ef>] notifier_call_chain+0x91/0xee
[ 69.820091] [<84e94e7d>] __blocking_notifier_call_chain+0x56/0x87
[ 69.820091] [<84e94ec8>] blocking_notifier_call_chain+0x1a/0x2a
[ 69.820091] [<84f49773>] out_of_memory+0x39/0x55a
[ 69.820091] [<84f4963c>] ? oom_zonelist_trylock+0x140/0x158
[ 69.820091] [<84f50213>] __alloc_pages_nodemask+0x967/0xb2e
[ 69.820091] [<84f62bb4>] shmem_getpage_gfp+0x477/0xa83
[ 69.820091] [<84f63281>] shmem_getpage+0x2d/0x40
[ 69.820091] [<84f641a9>] shmem_fault+0x1e8/0x233
[ 69.820091] [<84f78ae2>] __do_fault+0x37/0x95
[ 69.820091] [<84f7afea>] do_read_fault+0x2bf/0x410
[ 69.820091] [<84f7ba04>] handle_mm_fault+0x23c/0x1556
[ 69.820091] [<84e5c345>] __do_page_fault+0x792/0xbea
[ 69.820091] [<84f031fe>] ? tick_program_event+0x2d/0x40
[ 69.820091] [<84eecf95>] ? hrtimer_interrupt+0x1fc/0x343
[ 69.820091] [<84ebe651>] ? trace_hardirqs_off_caller+0x1df/0x257
[ 69.820091] [<84e57049>] ? kvm_async_pf_task_wake+0x236/0x236
[ 69.820091] [<84e5c7ef>] do_page_fault+0x52/0x64
[ 69.820091] [<84e57088>] do_async_page_fault+0x3f/0xe6
[ 69.820091] [<858cadf6>] error_code+0x42/0x48
[ 69.820091] [<84e900d8>] ? alloc_pid+0x298/0x535
[ 69.820091] [<84f729c0>] ? fault_in_pages_readable+0x62/0x92
[ 69.820091] [<84f73dd9>] copy_page_from_iter+0xef/0x34d
[ 69.820091] [<84f431b0>] ? wake_up_page+0x33/0x45
[ 69.820091] [<84f44539>] ? unlock_page+0x62/0x72
[ 69.820091] [<84f92954>] process_vm_rw_core+0x5da/0x7d0
[ 69.820091] [<84fa8d2f>] ? copy_from_user+0x3e/0x4e
[ 69.820091] [<84fa9fe6>] ? rw_copy_check_uvector+0xc8/0x1bf
[ 69.820091] [<84f92c81>] process_vm_rw+0x137/0x1c7
[ 69.820091] [<84ec6e1e>] ? lock_release+0x394/0x417
[ 69.820091] [<84fa8cb3>] ? file_end_write+0x3b/0x4b
[ 69.820091] [<84fa8aa1>] ? do_iter_readv_writev+0xbe/0xbe
[ 69.820091] [<84facbce>] ? __sb_end_write+0xcf/0xe4
[ 69.820091] [<84fa8cb3>] ? file_end_write+0x3b/0x4b
[ 69.820091] [<84fa9963>] ? vfs_write+0x1a9/0x1c4
[ 69.820091] [<858ca53e>] ? restore_all+0xf/0xf
[ 69.820091] [<84f92dad>] SyS_process_vm_writev+0x38/0x64
[ 69.820091] [<858ca505>] syscall_call+0x7/0x7
[ 69.820091] [<858c0000>] ? __schedule+0xa8/0x9b4
[ 69.980353] trinity-c0 invoked oom-killer: gfp_mask=0x200da, order=0, oom_score_adj=0
[ 69.981664] CPU: 0 PID: 3694 Comm: trinity-c0 Not tainted 3.19.0-rc1 #1
[ 69.982763] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 69.984531] 00000000 817efaa4 858b7132 816a09c0 817efaec 858b5ac3 85cbaffb 816a0c9c
[ 69.986092] 000200da 00000000 00000000 00000246 817efad4 858c901d 85e046ac 00000001
[ 69.987650] 817efaec 00000000 858e56e0 000200da 816a09c0 00000000 817efb10 84f48fec
[ 69.989203] Call Trace:
[ 69.989641] [<858b7132>] dump_stack+0xf3/0x192
[ 69.990405] [<858b5ac3>] dump_header+0x9e/0x2da
[ 69.991301] [<858c901d>] ? _raw_spin_unlock_irqrestore+0xbd/0x141
[ 69.992394] [<84f48fec>] oom_kill_process+0xac/0x521
[ 69.993255] [<84ec6e1e>] ? lock_release+0x394/0x417
[ 69.994098] [<84f49c45>] out_of_memory+0x50b/0x55a
Thanks,
Huang, Ying
_______________________________________________
LKP mailing list
LKP(a)linux.intel.com
5 years, 1 month
[xfs] dbe1b5ca263: +6.5% will-it-scale.per_thread_ops
by Huang Ying
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit dbe1b5ca26396b6c61d711c8ac4de13ebb02e9f6 ("xfs: Make xfs_vn_rename compliant with renameat2() syscall")
testbox/testcase/testparams: lkp-nex05/will-it-scale/performance-pwrite1
v3.19-rc1 dbe1b5ca26396b6c61d711c8ac
---------------- --------------------------
%stddev %change %stddev
\ | \
1131870 ± 0% +6.5% 1205531 ± 0% will-it-scale.per_thread_ops
1209729 ± 0% +5.8% 1280184 ± 0% will-it-scale.per_process_ops
0.54 ± 0% -3.1% 0.53 ± 1% will-it-scale.scalability
1400 ± 30% +174.5% 3842 ± 34% sched_debug.cpu#36.nr_switches
810 ± 33% +154.2% 2060 ± 25% sched_debug.cpu#36.ttwu_count
163 ± 41% +96.6% 320 ± 42% sched_debug.cpu#2.ttwu_local
242 ± 38% +71.4% 416 ± 19% slabinfo.blkdev_queue.active_objs
137 ± 28% +99.3% 274 ± 22% sched_debug.cpu#26.ttwu_local
29 ± 44% +116.0% 63 ± 28% sched_debug.cfs_rq[50]:/.tg_load_contrib
1296 ± 34% +41.5% 1835 ± 19% sched_debug.cpu#63.ttwu_local
405 ± 30% -42.3% 234 ± 15% sched_debug.cpu#56.sched_goidle
314 ± 27% +43.6% 452 ± 11% slabinfo.blkdev_queue.num_objs
980 ± 28% -37.7% 611 ± 13% sched_debug.cpu#56.nr_switches
684 ± 25% +40.5% 962 ± 20% sched_debug.cpu#10.ttwu_count
1.03 ± 2% -38.8% 0.63 ± 7% perf-profile.cpu-cycles.current_kernel_time.file_update_time.__generic_file_write_iter.generic_file_write_iter.new_sync_write
838 ± 25% -33.1% 560 ± 14% sched_debug.cpu#60.nr_switches
4870 ± 19% +25.8% 6127 ± 14% sched_debug.cpu#63.nr_switches
1443 ± 10% +39.9% 2019 ± 23% sched_debug.cpu#2.sched_count
39 ± 20% +55.1% 61 ± 16% latency_stats.max.call_rwsem_down_write_failed.SyS_mprotect.system_call_fastpath
336 ± 33% -37.8% 209 ± 12% sched_debug.cpu#60.sched_goidle
2.27 ± 12% -33.6% 1.51 ± 2% perf-profile.cpu-cycles.rw_verify_area.vfs_write.sys_pwrite64.system_call_fastpath.__libc_pwrite
394 ± 19% -31.5% 270 ± 13% sched_debug.cpu#52.sched_goidle
986 ± 19% -25.0% 740 ± 11% sched_debug.cpu#52.nr_switches
2.25 ± 4% -28.4% 1.61 ± 6% perf-profile.cpu-cycles.security_file_permission.rw_verify_area.vfs_write.sys_pwrite64.system_call_fastpath
257 ± 15% +52.9% 394 ± 28% sched_debug.cpu#10.ttwu_local
1.24 ± 10% -26.7% 0.91 ± 8% perf-profile.cpu-cycles.selinux_file_permission.security_file_permission.rw_verify_area.vfs_write.sys_pwrite64
1.12 ± 6% -27.7% 0.81 ± 8% perf-profile.cpu-cycles.rw_verify_area.vfs_write.sys_pwrite64.system_call_fastpath.__libc_pwrite64
3385 ± 10% +8.9% 3687 ± 8% sched_debug.cpu#39.curr->pid
4.01 ± 0% +27.4% 5.11 ± 1% perf-profile.cpu-cycles.file_update_time.__generic_file_write_iter.generic_file_write_iter.new_sync_write.vfs_write
1.05 ± 2% -23.8% 0.80 ± 5% perf-profile.cpu-cycles.iov_iter_fault_in_readable.__generic_file_write_iter.generic_file_write_iter.new_sync_write.vfs_write
0.83 ± 3% +24.7% 1.03 ± 1% perf-profile.cpu-cycles.current_fs_time.file_update_time.__generic_file_write_iter.generic_file_write_iter.new_sync_write
0.88 ± 2% +15.2% 1.02 ± 2% perf-profile.cpu-cycles.__sb_end_write.vfs_write.sys_pwrite64.system_call_fastpath.__libc_pwrite64
0.99 ± 1% +14.5% 1.14 ± 1% perf-profile.cpu-cycles.system_call.__libc_pwrite
2.60 ± 2% +11.7% 2.91 ± 0% perf-profile.cpu-cycles.__srcu_read_lock.fsnotify.vfs_write.sys_pwrite64.system_call_fastpath
3.56 ± 6% +12.4% 4.00 ± 4% perf-profile.cpu-cycles.unlock_page.shmem_write_end.generic_perform_write.__generic_file_write_iter.generic_file_write_iter
252 ± 0% +7.8% 272 ± 1% time.user_time
lkp-nex05: Nehalem-EX
Memory: 192G
will-it-scale.per_process_ops
1.4e+06 ++--O--------------O---------------------------------------------+
1.38e+06 O+ O O |
| O |
1.36e+06 ++ O |
1.34e+06 ++ |
| |
1.32e+06 ++ O |
1.3e+06 ++ O O O |
1.28e+06 ++ O O O O O |
| O O
1.26e+06 ++ |
1.24e+06 ++ |
| |
1.22e+06 ++ .*...*...*...*...*...*..* |
1.2e+06 *+--*---*--------------------------------------------------------+
will-it-scale.per_thread_ops
1.32e+06 ++---------------------------------------------------------------+
1.3e+06 ++ O O O |
O O O |
1.28e+06 ++ O |
1.26e+06 ++ |
| |
1.24e+06 ++ |
1.22e+06 ++ O O O |
1.2e+06 ++ O O O O O O O O
| |
1.18e+06 ++ |
1.16e+06 ++ |
| ..*... |
1.14e+06 *+.. .*...*...*...*. *..* |
1.12e+06 ++--*---*--------------------------------------------------------+
[*] bisect-good sample
[O] bisect-bad sample
To reproduce:
apt-get install ruby ruby-oj
git clone git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/setup-local job.yaml # the job file attached in this email
bin/run-local job.yaml
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Huang, Ying
_______________________________________________
LKP mailing list
LKP(a)linux.intel.com
5 years, 1 month
[ftrace] fef5aeeee9e: -27.2% boot-slabinfo.num_objs
by Huang Ying
FYI, we noticed the below changes on
commit fef5aeeee9e3717e7aea991a7ae9ff6a7a2d4c85 ("ftrace: Replace tramp_hash with old_*_hash to save space")
testbox/testcase/testparams: vm-kbuild-4G/boot/1
e1effa0144a1ddf5 fef5aeeee9e3717e7aea991a7a
---------------- --------------------------
%stddev %change %stddev
\ | \
437752 ± 0% -27.2% 318545 ± 0% boot-slabinfo.num_objs
vm-kbuild-4G: qemu-system-x86_64 -enable-kvm
Memory: 4G
boot-slabinfo.num_objs
440000 *+*--*-*-*------*----*-*-*--*--------*-*--*-*-*--*-----------------+
| *.* *. *.*..* |
420000 ++ |
| |
400000 ++ |
| |
380000 ++ |
| |
360000 ++ |
| |
340000 ++ |
| |
320000 O+O O O O O O O O O O O O O O O O O O O O O O O O O O
| O O O |
300000 ++-----------------------------------------------------------------+
[*] bisect-good sample
[O] bisect-bad sample
To reproduce:
apt-get install ruby ruby-oj
git clone git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/setup-local job.yaml # the job file attached in this email
bin/run-local job.yaml
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Huang, Ying
_______________________________________________
LKP mailing list
LKP(a)linux.intel.com
5 years, 1 month
