Re: [reboot] WARNING: CPU: 0 PID: 112 at kernel/events/core.c:5655 perf_swevent_add()

Hi Jiri, On Mon, Mar 10, 2014 at 01:53:19PM +0100, Jiri Olsa wrote: > On Sat, Mar 08, 2014 at 02:51:53PM +0800, Fengguang Wu wrote: > > > > Hi all, > > > > This is a very old WARNING, too old to be bisectable. The below 3 different > > back traces show that it

[m32r] ERROR: "memory_start" [fs/udf/udf.ko] undefined!

Hi Hirokazu, We noticed long standing build errors for m32104ut_defconfig and the below bisected "first bad commit" actually fixed something to make the kernel build go on to disclose these hidden errors. first "bad" commit: fc31c7716355a226b8ed4e16f4581e5c8fa53570 kbuild: include limits.h in su

Re: [mac80211_hwsim] BUG: unable to handle kernel paging request at ce1db404

Martin, These are long term bug and is still showing up in linux-next. It can be reliably reproduced with the below KVM script. #!/bin/bash kvm=( qemu-system-x86_64 -cpu kvm64 -enable-kvm -kernel $1 -smp 2 -m 256M -net nic,vlan=0,macaddr=00:00:00:00:00:00,

[perf_swevent_init] BUG: unable to handle kernel paging request at b1793514

Perhaps a related BUG. Here are 3 different back traces: [ 15.385846] sock: process `trinity-main' is using obsolete setsockopt SO_BSDCOMPAT [ 16.681572] BUG: unable to handle kernel paging request at b1793514 [ 16.681595] IP: [] atomic_inc+0x3/0x8 [ 16.681600] *pdpt = 0b203001 *p

Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

Hi Stefani, > So i tried my best, but without support it is impossible to find all > issues. But mostly what i get was bureaucracy afflictions > > I complied, but now it is time to help finding the issues. And not only > do a complain, sit back and wait. I feel sorry if that's what you perceived

Re: [qemu64,+smep,+smap] WARNING: CPU: 1 PID: 0 at arch/x86/kernel/cpu/amd.c:220 init_amd()

On Fri, Mar 07, 2014 at 02:11:50PM -0800, H. Peter Anvin wrote: > On 03/07/2014 02:06 PM, Dave Jones wrote: > > On Fri, Mar 07, 2014 at 10:38:56PM +0100, Borislav Petkov wrote: > > > > > * Another option would be if we change the f/m/s of "qemu64" so that > > > the test doesn't fire. > > > > >

Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

i7 XEON machine i would be able to test all > mutations of kernels. But i have not (despite i cannot pay the invoice). > > Also i get no support by people who ask me to do this work. I am really > pissed of. > > - Stefani > > Am Freitag, den 07.03.2014, 17:15 +0800 schrie

Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

Hi Stefani, On Fri, Mar 07, 2014 at 09:47:14AM +0100, Stefani Seibold wrote: > Hi Fengguang, > > i was now able to bring up the kernel on my KVM with some minior > changes. I kick out the PARIDE, switched to IDE and activated the VT > support. With this modifications the kernel boot and i get no

Re: [qemu64,+smep,+smap] WARNING: CPU: 1 PID: 0 at arch/x86/kernel/cpu/amd.c:220 init_amd()

On Thu, Mar 06, 2014 at 09:03:50PM -0800, H. Peter Anvin wrote: > On 03/06/2014 05:58 PM, Fengguang Wu wrote: > > Hi all, > > > > I find the below WARNING shows up only in > > > > qemu-system-x86_64 -cpu qemu64,+smep,+smap > > > > Yes, it

Re: [ACPI / hotplug / PCI] 1b360f44d00: -80.9% vm-scalability.stddev

On Wed, Mar 05, 2014 at 01:58:54PM +0100, Rafael J. Wysocki wrote: > On Wednesday, March 05, 2014 04:23:36 PM Fengguang Wu wrote: > > Hi Rafael, > > Hi, > > > I don't know why but we are glad to find the below changes on commit > > Do I understand c

[ACPI / hotplug / PCI] 1b360f44d00: -80.9% vm-scalability.stddev

Hi Rafael, I don't know why but we are glad to find the below changes on commit 1b360f44d009059e446532f29c1a889951e72667 ("ACPI / hotplug / PCI: Fix bridge removal race in handle_hotplug_event()") test case: brickland2/micro/vm-scalability/300s-anon-r-rand-mt d42f5da23400833 1b360f44d009059e4

Re: [blk-lib] 6a0608544e5: fileio -77.4% max latency, -5.7% throughput

On Wed, Mar 05, 2014 at 12:23:53PM +1100, Dave Chinner wrote: > On Wed, Mar 05, 2014 at 09:16:45AM +0800, Fengguang Wu wrote: > > On Tue, Mar 04, 2014 at 01:52:25PM -0800, Kent Overstreet wrote: > > > On Tue, Mar 04, 2014 at 09:21:30PM +0800, Fengguang Wu wrot

[sched/idle] c365c292d05: ltp.sched_rr_get_interval02.1.TFAIL

Hi Thomas, We noticed ltp/syscalls test regression on git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/idle commit: c365c292d05908c6ea6f32708f331e21033fe71d ("sched: Consider pi boosting in setscheduler()") Thanks, Fengguang -- To unsubscribe from this list: send the line "unsub

Re: [blk-lib] 6a0608544e5: fileio -77.4% max latency, -5.7% throughput

On Tue, Mar 04, 2014 at 01:52:25PM -0800, Kent Overstreet wrote: > On Tue, Mar 04, 2014 at 09:21:30PM +0800, Fengguang Wu wrote: > > Hi Kent, > > > > FYI, we noticed the below changes on > > > > git://evilpiepirate.org/~kent/lin

[blk-lib] 6a0608544e5: fileio -77.4% max latency, -5.7% throughput

Hi Kent, FYI, we noticed the below changes on git://evilpiepirate.org/~kent/linux-bcache.git for-jens commit 6a0608544e5672bd9a044c285119547eae41abe5 ("blk-lib.c: generic_make_request() handles large bios now") test case: snb-drag/sysbench/fileio/600s-100%-1HDD-ext4-64G-1024-seqrewr-sync 11541

[sched/balance] 18e6296b85e: -96.9% interrupts.RES

Hi Alex, FYI, we noticed the below changes on https://github.com/alexshi/power-scheduling.git single-balance commit 18e6296b85ea72c81aa485653d442ad88296d475 ("sched/balance: central balance prototype") test case: snb-drag/crypto/tcrypt/2s-301-319 598143917dc5ecf 18e6296b85ea72c81aa485653 --

[sched/balance] 815296e0446: -71.2% cpuidle.C3-SNB.time

Alex, FYI, we noticed the below changes on commit https://github.com/alexshi/power-scheduling.git single-balance 815296e0446ff6c405ef647082024ce3d8183e10 ("sched: unify imbalance bias for target group") test case: lkp-snb01/micro/aim7/compute bf0607d57b0b3ef 815296e0446ff6c405ef64708 --

[sched/balance] 598143917: -1.8% turbostat.Pkg_W

Alex, FYI, we noticed the below changes on commit 598143917dc5ecf11f0764de4166ee7c98e90aff ("sched: only do load balance on tick_do_timer_cpu") in your git tree https://github.com/alexshi/power-scheduling.git single-balance bc575710efe937e 598143917dc5ecf11f0764de4 --- -

[xfs] f876e446: +1.2% fileio.requests_per_sec

Hi Dave, We noticed the below changes on commit f876e44603ad091c840a5fae5b0753bbb421c037 ("xfs: always do log forces via the workqueue"): Basically there are +1.2% increased throughput with +29.5% increased context switches. test box: NHM test case: fileio rndwr-sync v3.14-rc1 f876e44603

Re: [sched/balance] 7511dd0a7: +2.1e+05% context switches

On Thu, Feb 20, 2014 at 03:21:29PM +0800, Alex Shi wrote: > On 02/19/2014 09:00 PM, Fengguang Wu wrote: > > bc575710efe937e 7511dd0a73aaf2ca4bcd829f9 > > --- - > > 2029 ~ 0%+222.9% 6551 ~17% > > lkp-snb01/micro/w

Re: [sctp] ef2820a735: -50% netperf Throughput_Mbps

Hi Matija, On Wed, Feb 19, 2014 at 06:06:34PM +0100, Matija Glavinic Pecotic wrote: > Hello Fengguang, > > On 02/19/2014 02:20 PM, ext Fengguang Wu wrote: > > Hi Matija, > > > > We noticed the below changes on commit > > ef2820a735f74ea60335f8ba3801b844f0cb

[x86] 339a3922f6: +4.3% aim7 jobs-per-min

Hi Maarten, We are glad to find that your commit 339a3922f68dcb7d93001f07b7e914d5cf6c066d ("decrease useless padding") increased aim disk_src performance by 4.3%: 74833276be6802b 339a3922f68dcb7d93001f07b --- - 511685 ~ 0% +4.3% 533571 ~ 0%

[cpufreq/intel_pstate] 1abc4b20b85: +7.3% turbostat.Pkg_W

Hi Dirk, FYI, we noticed the below changes on commit 1abc4b20b85b42e8573957e54b193385cf48b0d6 ("cpufreq / intel_pstate: remove idle time and duration from sample and calculations"): test case: snb-drag/sysbench/fileio/600s-100%-1HDD-btrfs-64G-1024-seqrd-sync 559f56c70fc90bd 1abc4b20b85b42e857

[sctp] ef2820a735: -50% netperf Throughput_Mbps

Hi Matija, We noticed the below changes on commit ef2820a735f74ea60335f8ba3801b844f0cb184d (" net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer") in netperf SCTP_STREAM tests: cd0f0b95fd2cd2b ef2820a735f74ea60335f8ba3 --- ---

[vfs] 73c12e50a: +13349.5% softirqs.RCU

Hi Eric, FYI, we noticed the below changes on commit 73c12e50af3a756137071c1e1c1e99cffcbaa835 ("vfs: Lazily remove mounts on unlinked files and directories."): test case: dbench 5c39777e797e7ba 73c12e50af3a756137071c1e1 --- - 6.22 ~ 0%+195

Re: [PATCH] wil6210: Fix switch operator "missing break?" warning

Hi Alexander, On Mon, Feb 10, 2014 at 01:16:38PM +0100, Alexander Gordeev wrote: > On Mon, Feb 10, 2014 at 12:54:13PM +0200, Vladimir Kondratiev wrote: > > I can't reproduce this warning. What tools used to get it? > > Fengguang? This is a smatch warning: http://smatch.sourceforge.net/

Re: [process_vm_access] BUG: unable to handle kernel paging request at fffffff27b92dd20

On Mon, Feb 10, 2014 at 07:22:31PM +0800, Fengguang Wu wrote: > Hi Al, > > We noticed the below oops since commit > 68a25f08c9bec07ad95e55a01b127168e43aed84 > ("process_vm_access: take get_user_pages/put_pages one level up") > while running ltp tests inside kvm. >

Re: [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038

On Sat, Feb 08, 2014 at 03:10:37PM -0500, Tejun Heo wrote: > Hello, David, Fengguang, Chris. > > On Fri, Feb 07, 2014 at 01:13:06PM -0800, David Rientjes wrote: > > On Fri, 7 Feb 2014, Fengguang Wu wrote: > > > > > On Fri, Feb 07, 2014 at 02:13:59AM -0800, David Rie

Re: [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038

Hi Filipe, > If you disable CONFIG_BTRFS_FS_RUN_SANITY_TESTS, does it still crash? I tried disabling CONFIG_BTRFS_FS_RUN_SANITY_TESTS in the reported 3 randconfigs and they all boot fine. Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of

Re: [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038

> If you disable CONFIG_BTRFS_FS_RUN_SANITY_TESTS, does it still crash? Good idea! I've queued test jobs for that config. However sorry that I'll be offline for the next 2 days. So please expect some delays. Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kern

Re: [btrfs] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038

On Fri, Feb 07, 2014 at 02:13:59AM -0800, David Rientjes wrote: > On Fri, 7 Feb 2014, Fengguang Wu wrote: > > > [1.625020] BTRFS: selftest: Running btrfs_split_item tests > > [1.627004] BTRFS: selftest: Running find delalloc tests > > [2.289182] tsc:

Re: [slub] WARNING: CPU: 1 PID: 1 at mm/slub.c:992 deactivate_slab()

On Thu, Feb 06, 2014 at 01:41:10PM -0800, David Rientjes wrote: > On Wed, 5 Feb 2014, David Rientjes wrote: > > > Ah, that's because the patch didn't go through Pekka's slab tree but went > > into -mm instead so we have to wait for another -mm. However, the traces > > from linux-next-20140204 t

Re: [sched/preempt] INFO: rcu_sched self-detected stall on CPU { 1}

On Thu, Feb 06, 2014 at 07:46:35PM +0800, Fengguang Wu wrote: > On Thu, Feb 06, 2014 at 12:27:31PM +0100, Peter Zijlstra wrote: > > On Thu, Feb 06, 2014 at 05:56:46PM +0800, Fengguang Wu wrote: > > > Hi Peter, > > > > > > We noticed the below RCU stalls wh

Re: [sched/preempt] INFO: rcu_sched self-detected stall on CPU { 1}

On Thu, Feb 06, 2014 at 12:27:31PM +0100, Peter Zijlstra wrote: > On Thu, Feb 06, 2014 at 05:56:46PM +0800, Fengguang Wu wrote: > > Hi Peter, > > > > We noticed the below RCU stalls which will block the system. > > The problem is

Re: WARNING: at arch/x86/kernel/smpboot.c:324 topology_sane()

On Thu, Feb 06, 2014 at 06:05:37PM +0800, Tang Chen wrote: > On 02/06/2014 05:44 PM, Fengguang Wu wrote: > >Hi Tang, > > > >We noticed the below warning and the first bad commit is > > > >commit e8d1955258091e4c92d5a975ebd7fd8a98f5d30f > >Author: Tang

Re: [slub] WARNING: CPU: 1 PID: 1 at mm/slub.c:992 deactivate_slab()

On Wed, Feb 05, 2014 at 12:10:48AM -0800, David Rientjes wrote: > On Wed, 5 Feb 2014, Fengguang Wu wrote: > > > Greetings, > > > > I got the below dmesg and the first bad commit is in upstream > > > > commit c65c1877bd6826ce0d9713d76e30a7bed8e

Re: [PATCH] MAINTAINERS: Update drm/i915 git repo

On Wed, Feb 05, 2014 at 08:54:15AM +0100, Daniel Vetter wrote: > On Tue, Feb 4, 2014 at 8:37 PM, Daniel Vetter wrote: > > On Tue, Feb 4, 2014 at 8:00 PM, Daniel Vetter > > wrote: > >> Moved to a common location so that Jani also can push to it, to avoid > >> moving it every time I go on vacation

[btrfs/i_size] xfstests generic/299 TFAIL

Hi Steven, We noticed xfstests generic/299 TFAIL on btrfs since commit 9fe55eea7e4b444bafc42facc2d1d2847275 Author: Steven Whitehouse AuthorDate: Fri Jan 24 14:42:22 2014 + Commit: Al Viro CommitDate: Sun Jan 26 08:26:42 2014 -0500 Fix race when checking i_size on direct i/

Re: [slub shrink] 0f6934bf16: +191.9% vmstat.system.cs

Hi Dave, I got more complete results for https://github.com/hansendc/linux.git slub-reshrink-for-Fengguang-20140113, It looks mostly good. There are regressions in - netperf.Throughput_Mbps - dbench.throughput-MB/sec - xfstests.generic.256.seconds However the others are all improveme

Re: [PATCH] mm: slub: fix page->_count corruption (again)

Hi Dave, > > Fengguang, could you run a set of tests for the top patch in this branch > > to see if we'd be giving much up by axing the code? > > > > > > https://github.com/hansendc/linux/tree/slub-nocmpxchg-for-Fengguang-20140128 > > Sure, I've queued tests for the branch. Will report back

Re: [PATCH] mm: slub: fix page->_count corruption (again)

On Tue, Jan 28, 2014 at 03:52:47PM -0800, Dave Hansen wrote: > On 01/28/2014 03:29 PM, Andrew Morton wrote: > > On Tue, 28 Jan 2014 15:17:22 -0800 Dave Hansen wrote: > > This code is borderline insane. > > No argument here. > > > Yes, struct page is special and it's worth spending time and doing

Re: [rcu] c0f4dfd4f9: -65% softirqs.RCU

On Mon, Jan 27, 2014 at 09:06:02AM -0800, Paul E. McKenney wrote: > On Fri, Jan 24, 2014 at 07:11:30PM +0800, Fengguang Wu wrote: > > On Mon, Jan 20, 2014 at 08:41:00PM -0800, Paul E. McKenney wrote: > > > On Mon, Jan 20, 2014 at 08:29:12PM +0800, Fengguang Wu wrote: > >

Re: [percpu_counter] 74e72f894: -47.6% aim7 jobs-per-min

Hi Ming Lei, On Fri, Jan 17, 2014 at 06:56:24PM +0800, Ming Lei wrote: > Hi Fengguang, > > On Fri, Jan 17, 2014 at 6:20 PM, Fengguang Wu wrote: > > Ming Lei, > > > > We noticed that commit 74e72f894 ("lib/percpu_counter.c: fix > > __percpu_counter_add()&

Re: [numa shrinker] 9b17c62382: -36.6% regression on sparse file copy

Hi Dave, On Wed, Jan 15, 2014 at 11:18:27AM +1100, Dave Chinner wrote: > On Thu, Jan 09, 2014 at 10:57:15AM +0800, Fengguang Wu wrote: > > Hi Dave, > > > > As you suggested, I added tests for ext4 and btrfs, the results are > > the same. > > > > Then I t

Re: [mac80211] BUG: unable to handle kernel paging request at 6b6b6b8f

On Fri, Jan 24, 2014 at 01:17:50PM +0100, Johannes Berg wrote: > On Fri, 2014-01-24 at 20:08 +0800, Fengguang Wu wrote: > > Hi Johannes, > > > > The BUG does not show up in linux-next 20140124, is it fixed now? > > It isn't in linux-next yet I believe (mac80211-

[rcu] c0f4dfd4f9: -53% perf-stat.cpu-migrations

Hi Paul, Just FYI, we noticed -53% perf-stat.cpu-migrations in dd write tests on btrfs, which looks good. First good commit is commit c0f4dfd4f90f1667d234d21f15153ea09a2eaa66 Author: Paul E. McKenney AuthorDate: Fri Dec 28 11:30:36 2012 -0800 Commit: Paul E. McKenney CommitDate: Tue Mar

Re: [rcu] c0f4dfd4f9: -65% softirqs.RCU

On Mon, Jan 20, 2014 at 08:41:00PM -0800, Paul E. McKenney wrote: > On Mon, Jan 20, 2014 at 08:29:12PM +0800, Fengguang Wu wrote: > > On Sun, Jan 19, 2014 at 03:11:14PM -0800, Paul E. McKenney wrote: > > > On Sun, Jan 19, 2014 at 08:16:08PM +0800, Fengguang Wu wrot

[rcu] 878d7439d0: -100% softirqs.RCU

Hi Eric, Just FYI, we noticed the below changes in old commit 878d7439d0 ("rcu: Fix batch-limit size problem") in test case will-it-scale/open1: 62da1921292ef78 878d7439d0f45a95869e41757 --- - 0.00 ~200% +60900.0% 1.22 ~18% TOTAL perf-profi

Re: [slub shrink] 0f6934bf16: +191.9% vmstat.system.cs

Hi Dave, I retested the will-it-scale/read2 case with perf profile enabled, and here are the new comparison results. It shows that there are increased overheads in shmem_getpage_gfp(). If you'd like to collect more data, feel free to tell me. 9a0bb2966efbf30 0f6934bf1695682e7ced973f6 -

[ipc] 5769cf63: LTP semget02 TFAILs

Hi Davidlohr, We noticed LTP test failures ltp.msgget02.1.TFAIL ltp.semget02.2.TFAIL ltp.semget02.3.TFAIL and the first bad commit is commit 5769cf6355d87f63906b3e51887eff7017c39217 Author: Davidlohr Bueso AuthorDate: Wed Jan 15 16:56:01 2014 +1100 Commit: Steph

Re: [slub shrink] 0f6934bf16: +191.9% vmstat.system.cs

est.py are computed and is different for machines with different number of CPUs. The goal of the computation is so that the test wall time on different machines will be equally ~5 minutes. In a system with 120 CPUs, the numbers will be: ./runtest.py brk1 16 1 120 15 30 45 60 90 Thanks, Fengguang >

[tip:x86/intel-mid] x86, intel_mid: Replace memcpy with struct assignment

Commit-ID: ee87c751d88f9b03fee7349556817fe80c113b32 Gitweb: http://git.kernel.org/tip/ee87c751d88f9b03fee7349556817fe80c113b32 Author: Fengguang Wu AuthorDate: Thu, 16 Jan 2014 16:13:08 -0800 Committer: H. Peter Anvin CommitDate: Thu, 16 Jan 2014 16:11:10 -0800 x86, intel_mid: Replace

Re: [sched] 73628fba4: +69% context switches

On Thu, Jan 16, 2014 at 10:46:01AM +0800, Alex Shi wrote: > > >> > > >> What's about the aim7 shell_rtns_1 and shared throughput? > >>> > > > >>> > > The throughputs remain the same. We only report changed numbers. > >> > > >> > So many interrupt increase doesn't cause any performance

Re: [sched] 73628fba4: +69% context switches

On Thu, Jan 16, 2014 at 10:02:06AM +0800, Alex Shi wrote: > On 01/16/2014 09:23 AM, Fengguang Wu wrote: > > On Mon, Jan 13, 2014 at 01:57:30PM +0800, Alex Shi wrote: > >> On 01/11/2014 06:19 PM, Fengguang Wu wrote: > >>> Alex, > >>> > >>> FYI,

[sched] b75e43bb77d: +87% hackbench.throughput

Alex, We noticed that commit b75e43bb77d ("sched: find the latest idle cpu") increased hackbench throughput by +87% in test case hackbench 1600%-threads-pipe on a 2S SNB server. v3.13-rc7 b75e43bb77df14e2209532c1e --- - 171792 ~ 0% +87.0% 32

Re: [sched] 73628fba4: +69% context switches

On Mon, Jan 13, 2014 at 01:57:30PM +0800, Alex Shi wrote: > On 01/11/2014 06:19 PM, Fengguang Wu wrote: > > Alex, > > > > FYI, we find much increased interrupts and context switches introduced > > by commit 73628fba4 ("sched: unify imbalance bias for target g

Re: [x86, kaslr] PANIC: early exception 0e rip 10:ffffffff8ae04c6e error 0 cr2 ffffffff81972b28

On Wed, Jan 15, 2014 at 02:32:52PM -0800, Kees Cook wrote: > On Wed, Jan 15, 2014 at 4:24 AM, Fengguang Wu wrote: > > Kees, > > > > This script can reproduce the problem. Please modify the -initrd line > > before use. > > > > Usage: > > ./

Re: [sched] d50dde5a1: LTP sched_setparam* TFAILs

On Wed, Jan 15, 2014 at 02:09:38PM +0100, Peter Zijlstra wrote: > On Wed, Jan 15, 2014 at 08:47:39PM +0800, Fengguang Wu wrote: > > Hi Dario, > > > > We notice the below LTP failures since commit d50dde5a1 ("sched: Add > > new scheduler syscalls to support a

[sched] d50dde5a1: LTP sched_setparam* TFAILs

Hi Dario, We notice the below LTP failures since commit d50dde5a1 ("sched: Add new scheduler syscalls to support an extended scheduling parameters ABI") in tip tree's sched/core branch: ltp.sched_setparam02.1.TFAIL ltp.sched_setparam02.2.TFAIL ltp.sched_setparam02.3.TFAIL ltp.sched_setparam03.1.T

Re: [x86, kaslr] BUG: kernel boot hang

On Tue, Jan 14, 2014 at 02:33:15PM -0800, Kees Cook wrote: > On Tue, Jan 14, 2014 at 5:31 AM, Fengguang Wu wrote: > > Greetings, > > > > I got the below dmesg and the first bad commit is > > > > commit 82fa9637a2ba285bcc7c5050c73010b2c1b3d803 > > Author:

Re: [x86, kaslr] PANIC: early exception 0e rip 10:ffffffff8ae04c6e error 0 cr2 ffffffff81972b28

Kees, This script can reproduce the problem. Please modify the -initrd line before use. Usage: ./kvm-0day.sh vmlinuz-3.12.0-rc4-8-g6e6a493 #!/bin/bash kernel=$1 kvm=( qemu-system-x86_64 -cpu kvm64 -enable-kvm -kernel $kernel -initrd /kernel-tests/initrd/yoct

Re: [x86, kaslr] BUG: kernel boot hang

On Tue, Jan 14, 2014 at 10:26:42AM -0800, Kees Cook wrote: > On Tue, Jan 14, 2014 at 5:31 AM, Fengguang Wu wrote: > > Greetings, > > > > I got the below dmesg and the first bad commit is > > > > commit 82fa9637a2ba285bcc7c5050c73010b2c1b3d803 > > Author:

Re: [PATCH 0/9] re-shrink 'struct page' when SLUB is on.

> > So, I think > > that it is better to get more benchmark results to this patchset for > > convincing > > ourselves. If possible, how about asking Fengguang to run whole set of > > his benchmarks before going forward? > > Cc'ing him. My pleasure. Is there a git tree for the patches? Git trees

[GIT PULL] writeback data corruption fix

Linus, Please pull a writeback fix, it has been in linux-next for one month. The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e: Linux 3.13-rc3 (2013-12-06 09:34:04 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lin

Re: [ipv6_vti.c] INFO: trying to register non-static key.

On Sat, Jan 11, 2014 at 07:45:02PM -0800, David Miller wrote: > From: Fengguang Wu > Date: Sun, 12 Jan 2014 07:10:23 +0800 > > > Here is a warning introduced by commit 469bdcefd ("ipv6: fix the use > > of pcpu_tstats in ip6_vti.c"): > > It isn't fixed

[sched] 73628fba4: +69% context switches

Alex, FYI, we find much increased interrupts and context switches introduced by commit 73628fba4 ("sched: unify imbalance bias for target group") in your noload branch: 7bea8c18805a5f1 73628fba451ae72221b155696 --- - 14979 ~ 4% +1304.8% 210434

[xfs] c91c46c12: xfstests generic/313 regression

Hi Christoph, We find this commit failed xfstests generic/313. Attached is our kconfig. c91c46c12768daac8486dff0f74bc52c2ec974cd is the first bad commit commit c91c46c12768daac8486dff0f74bc52c2ec974cd Author: Christoph Hellwig AuthorDate: Mon Nov 18 05:10:52 2013 -0800 Commit: Ben Myers

warning: (PPC_PSERIES && ..) selects HOTPLUG_CPU which has unmet direct dependencies (SMP && ..))

tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 7d1c153ab373a5c07feb97eaf4e4bcad5bfc262e commit: bb07b00be77fb33274cb44a03bdbf2471e556189 Merge 3.10-rc6 into driver-core-next date: 7 months ago config: make ARCH=powerpc mpc86xx_defconfig All warnings: wa

Re: [PATCH V3 Resend] cpufreq: create cpufreq_generic_get() routine

Hi Viresh, > @Fengguang: Would it make sense to add build tests for all ARM > defconfigs in your build system? I thought its already there :) > That way I can always be sure that my stuff (would be helpful for > others as well though) isn't breaking build (Atleast) for any platform. Sure. I just

Re: [numa shrinker] 9b17c62382: -36.6% regression on sparse file copy

On Tue, Jan 07, 2014 at 12:10:42AM +1100, Dave Chinner wrote: > On Mon, Jan 06, 2014 at 04:20:48PM +0800, fengguang...@intel.com wrote: > > Hi Dave, > > > > We noticed throughput drop in test case > > > > vm-scalability/300s-lru-file-readtwice (*) > > > > between v3.11 and v3.12, and it'

Re: perf-stat changes after "Use hrtimers for event multiplexing"

imer tick does not occur when a core is idle > when using a tickless kernel. Thus, the quality of the results with > hrtimers should be improved. OK, got it. Thanks for the explanations! Thanks, Fengguang > > On Sun, Jan 5, 2014 at 2:14 AM, Fengguang Wu wrote: > > On Sat, Jan

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

On Mon, Jan 06, 2014 at 04:47:38PM -0800, Muthu Kumar wrote: > OK, after a bit more staring I believe the correct fix is the following. > > Fengguang, Please try this one? Yes, it runs fine now! Tested-by: Fengguang Wu Thanks, Fengguang > > In btrfs_end_bio(

Re: [sched] 23f0d2093c: -12.6% regression on sparse file copy

Hi Joonsoo, On Mon, Jan 06, 2014 at 09:30:52AM +0900, Joonsoo Kim wrote: > On Sun, Jan 05, 2014 at 05:04:56PM +0800, fengguang...@intel.com wrote: > > Hi Joonsoo, > > > > We noticed the below changes for commit 23f0d2093c ("sched: Factor out > > code to should_we_balance()") in test vm-scalabilit

[sched] 23f0d2093c: -12.6% regression on sparse file copy

Hi Joonsoo, We noticed the below changes for commit 23f0d2093c ("sched: Factor out code to should_we_balance()") in test vm-scalability/300s-lru-file-readtwice 95a79b805b935f4 23f0d2093c789e612185180c4 --- - ==> 4.45 ~ 5% +1777.7%

[pipe] b8597fdc23: -8% regression of hackbench throughput

Hi Dmitry, We measured some 8% drop of hackbench throughput with your small commit b8597fdc23 ("fs/pipe.c: skip file_update_time on frozen fs"). Comparing to its parent commit, we also see increased context switches: 5b6e04beb19abc9 b8597fdc23f8f6e26a531e9a7 --- --

Re: perf-stat changes after "Use hrtimers for event multiplexing"

On Sat, Jan 04, 2014 at 08:02:28PM +0100, Peter Zijlstra wrote: > On Thu, Jan 02, 2014 at 02:12:42PM +0800, fengguang...@intel.com wrote: > > Greetings, > > > > We noticed many perf-stat changes between commit 9e6302056f ("perf: Use > > hrtimers for event multiplexing") and its parent commit ab573

1be41b78: +18% increased btrfs write throughput

Hi Josef, FYI. We are doing 0day performance tests and happen to notice that btrfs write throughput increased considerably during v3.10-11 time frame: v3.10 v3.11 v3.12 v3.13-rc6 --- -

Re: [sched] perf-stat.cpu-migrations changes in dd write test

On Wed, Dec 25, 2013 at 11:30:27AM +0800, Alex Shi wrote: > On 12/23/2013 01:24 PM, Fengguang Wu wrote: > > On Mon, Dec 23, 2013 at 01:19:04PM +0800, Alex Shi wrote: > >> On 12/22/2013 08:30 AM, fengguang...@intel.com wrote: > >>> Alex, > >>> > >>

Re: [sched] perf-stat.cpu-migrations changes in dd write test

On Mon, Dec 23, 2013 at 01:19:04PM +0800, Alex Shi wrote: > On 12/22/2013 08:30 AM, fengguang...@intel.com wrote: > > Alex, > > > > We noticed some perf-stat.cpu-migrations changes by your commit > > Thanks for your wonder testing, Fengguang! > How many CPU in your system and how many dd task run

5d4cf996cf1: -84.0% fileio.request_latency_max_ms

113.50 ( 0.00%) 24.16 ( 78.71%) It's eliminated for one machine and reduced for another. Signed-off-by: Mel Gorman Signed-off-by: Peter Zijlstra Cc: Alex Shi Cc: Andrew Morton Cc: Fengguang Wu Cc: H Peter Anvin Cc: Linus Torvalds Link:

fff4068cba48: +82.0% vm-scalability.throughput

Johannes, I'm glad to report that the below commit results in large increase of performance in our vm-scalability/1T-anon-w-seq testcase. commit fff4068cba484e6b0abe334ed6b15d5a215a3b25 Author: Johannes Weiner Date: Fri Dec 20 14:54:12 2013 + mm: page_alloc: revert NUMA aspect of fair

[sched] perf-stat.cpu-migrations changes in dd write test

Alex, We noticed some perf-stat.cpu-migrations changes by your commit 6eb8b571283e64e96ca1a91aad085f9e08f857f0 is the first bad commit commit 6eb8b571283e64e96ca1a91aad085f9e08f857f0 Author: Alex Shi Date: Tue Nov 19 20:29:51 2013 +0800 sched: remove rq->cpu_load[load_idx] array

Re: [net-next/master PATCH] lib: fix compile warning in hashlib_init

ult] > /git/linux/include/asm-generic/hash.h:5:20: note: expected 'struct > arch_hash_ops *' but argument is of type 'struct fast_hash_ops *' > > Reported-by: Fengguang Wu > Signed-off-by: Wanlong Gao > --- > include/asm-generic/hash.h | 4 ++-- > 1 fi

Re: [mlankhorst:rebase-wip 10/28] Warning(drivers/base/fence.c:35): cannot understand function prototype: 'atomic_t fence_context_counter = ATOMIC_INIT(0); '

On Wed, Dec 18, 2013 at 12:15:15PM +0100, Maarten Lankhorst wrote: > op 18-12-13 12:09, kbuild test robot schreef: > > tree: git://people.freedesktop.org/~mlankhorst/linux rebase-wip > > head: f4860763bb15e72067344fdf961be339d029f9a6 > > commit: 57c3e34f8e55cc2c909daa88ce4eefdf97372f9b [10/28]

Re: [PATCH 0/4] Fix ebizzy performance regression due to X86 TLB range flush v2

Hi Mel, I'd like to share some test numbers with your patches applied on top of v3.13-rc3. Basically there are 1) no big performance changes 76628486 -0.7% 76107841 TOTAL vm-scalability.throughput 407038 +1.2% 412032 TOTAL hackbench.throughput 5

Re: mqueue perf data

On Tue, Dec 10, 2013 at 03:49:38PM +0800, Wanlong Gao wrote: > Hi Fengguang, > > > Do we need to stat out the perf data of mqueue test in kernel_selftests? > It's like following. They look like performance data, except that the test time is so short that I'm not sure they are reliable enough. If

Re: [PATCH] devtmpfs: Calling delete_path() only when necessary

> Hi, Fengguang > Can you help to add this patch to your test systems? > It's a one-line change, you can find the patch at > https://patchwork.kernel.org/patch/3192361/ Hi Axel, Do you have a public git tree? If not, I'd like to take this chance to encourage you to setup one. The best work flow i

Re: [PATCH] block: Employ u64_stats_init()

On Tue, Nov 12, 2013 at 07:42:14PM -0800, John Stultz wrote: > From: Peter Zijlstra > > Now that seqcounts are lockdep enabled objects, we need to properly > initialize them. It works! Tested-by: Fengguang Wu /kernel/i386-randconfig-j7-11082318/cb460d7163af828b404eeb6e06cb

Re: [seqcount] INFO: trying to register non-static key.

On Tue, Nov 12, 2013 at 04:29:56PM +0100, Peter Zijlstra wrote: > On Tue, Nov 12, 2013 at 10:15:41AM -0500, Vivek Goyal wrote: > > I see that we allocate per cpu stats but don't do any initializations. > > > > static void tg_stats_alloc_fn(struct work_struct *work) > > { > > static struct

Re: [sched/get_online_cpus] INFO: task swapper/0:1 blocked for more than 120 seconds.

On Mon, Nov 11, 2013 at 05:20:22PM +0100, Peter Zijlstra wrote: > On Mon, Nov 11, 2013 at 03:47:11PM +0800, Michael wang wrote: > > Hi, Fengguang > > > > On 11/10/2013 06:16 PM, Fengguang Wu wrote: > > > Greetings, > > > > > > I got the below dm

Re: [seqcount] INFO: trying to register non-static key.

On Mon, Nov 11, 2013 at 04:45:51PM +0100, Peter Zijlstra wrote: > On Mon, Nov 11, 2013 at 09:29:27AM +0800, Fengguang Wu wrote: > > Greetings, > > > > I got the below dmesg and the first bad commit is > > > > commit 1ca7d67cf5d5a2aef26a8d9afd789006fa098347

[raid5] kernel BUG at drivers/md/raid5.c:701!

28cc2127527dcba2a0817afa8fd5a33c9e023090 is the first bad commit commit 28cc2127527dcba2a0817afa8fd5a33c9e023090 Author: Shaohua Li Date: Tue Sep 10 15:37:56 2013 +0800 raid5: relieve lock contention in get_active_stripe() get_active_stripe() is the last place we have lock contenti

Re: [vfsmounts] WARNING: CPU: 1 PID: 479 at fs/dcache.c:385 d_lru_del()

On Sat, Nov 09, 2013 at 05:19:31AM +, Al Viro wrote: > On Sat, Nov 09, 2013 at 11:06:36AM +0800, Fengguang Wu wrote: > > Greetings, > > > > I got the below dmesg and the first bad commit is > > > > commit 84550b9356af50c7cbd6b6ce6e8fd06585eebf14 > > Aut

Re: [vfs] BUG: spinlock trylock failure on UP on CPU#0, swapper/0

On Thu, Nov 07, 2013 at 04:30:31AM -0800, Christoph Hellwig wrote: > On Thu, Nov 07, 2013 at 08:10:42PM +0800, Fengguang Wu wrote: > > Greetings, > > > > I got the below dmesg and the first bad commit seems to be > > > > commit 1247c74b4f3f3725a8bd8dc0bbd22baa2

Re: [virtio_blk] WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:526 sysfs_add_one()

Hi Jens, On Mon, Nov 04, 2013 at 03:58:41PM -0700, Jens Axboe wrote: > On 11/04/2013 07:10 AM, Fengguang Wu wrote: > > Hi Jens, > > > > I'm not very sure about this bisect, but anyway it'd be good to inform > > you of a possi

Re: [virtio-net] BUG: sleeping function called from invalid context at kernel/mutex.c:616

I noticed that this fix is still not upstreamed. Any chance to push it to Linus before the 3.12 release? > >From 01e6c3f71c202aa02e4feda169e7cc9fb24193f5 Mon Sep 17 00:00:00 2001 > From: Jason Wang > Date: Mon, 21 Oct 2013 20:39:09 +0800 > Subject: [PATCH] virtio-net: fix > > --- > drivers/net/

Re: Disabling in-memory write cache for x86-64 in Linux II

// Sorry for the late response! I'm in marriage leave these days. :) On Tue, Oct 29, 2013 at 03:42:08PM -0700, Linus Torvalds wrote: > On Tue, Oct 29, 2013 at 3:13 PM, Jan Kara wrote: > > > > So I think we both realize this is only about what the default should be. > > Yes. Most people will us

Re: [RFC PATCH -next] Fix printk_once build errors due to __read_mostly

Hi Joe, On Wed, Oct 30, 2013 at 09:07:45AM -0700, Joe Perches wrote: > On Wed, 2013-10-30 at 10:18 +, James Hogan wrote: > > Commit 3e39c1ab04ba (printk: mark printk_once test variable > > __read_mostly) added __read_mostly to the __print_once bool in the > > printk_once() macro, but __read_mo

Re: [virtio-net] BUG: sleeping function called from invalid context at kernel/mutex.c:616

On Mon, Oct 28, 2013 at 01:44:04PM +0800, Jason Wang wrote: > On 10/24/2013 07:20 AM, Fengguang Wu wrote: > > Yes it reduces the sleeping function bug: > > > > /kernel/x86_64-lkp-CONFIG_SCSI_DEBUG/7c4ed2767afb813493b

Re: Disabling in-memory write cache for x86-64 in Linux II

On Fri, Oct 25, 2013 at 09:40:13PM +0200, Diego Calleja wrote: > El Viernes, 25 de octubre de 2013 18:26:23 Artem S. Tashkinov escribió: > > Oct 25, 2013 05:26:45 PM, david wrote: > > >actually, I think the problem is more the impact of the huge write later > > >on. > > Exactly. And not being able

<    4   5   6   7   8   9   10   11   12   13   >