Re: [PATCH] rcu: Reword help of RCU_TRACE option

On 10/06/2016 03:45 PM, Paul E. McKenney wrote: > On Wed, Oct 05, 2016 at 05:18:09PM +0300, Nikolay Borisov wrote: >> >> >> On 10/05/2016 05:03 PM, Paul E. McKenney wrote: >>> On Wed, Oct 05, 2016 at 10:06:21AM +0300, Nikolay Borisov wrote: >>>> Explic

Re: [PATCH] rcu: Reword help of RCU_TRACE option

On 10/05/2016 05:03 PM, Paul E. McKenney wrote: > On Wed, Oct 05, 2016 at 10:06:21AM +0300, Nikolay Borisov wrote: >> Explicitly state that enabling RCU_TRACE enables more >> tracepoints and not just "additional tracing". >> >> Signed-off-by: Nikolay Borisov

Re: [PATCH] rcu: Reword help of RCU_TRACE option

On 10/05/2016 05:03 PM, Paul E. McKenney wrote: > On Wed, Oct 05, 2016 at 10:06:21AM +0300, Nikolay Borisov wrote: >> Explicitly state that enabling RCU_TRACE enables more >> tracepoints and not just "additional tracing". >> >> Signed-off-by: Nik

[PATCH] rcu: Reword help of RCU_TRACE option

Explicitly state that enabling RCU_TRACE enables more tracepoints and not just "additional tracing". Signed-off-by: Nikolay Borisov <ker...@kyup.com> --- Hello Paul, Following our latest conversation re. enabling RCU tracing I had to actually go and look into the code to s

[PATCH] rcu: Reword help of RCU_TRACE option

Explicitly state that enabling RCU_TRACE enables more tracepoints and not just "additional tracing". Signed-off-by: Nikolay Borisov --- Hello Paul, Following our latest conversation re. enabling RCU tracing I had to actually go and look into the code to see which opti

more hangs in the tty layer

73/ To me this seems like a lost wakeup event, especially that I've seen patches flying around fixing such issues. Unfortunately I cannot reliably reproduce this and booting a production machine with lockdep would be problematic. Regards, Nikolay

more hangs in the tty layer

73/ To me this seems like a lost wakeup event, especially that I've seen patches flying around fixing such issues. Unfortunately I cannot reliably reproduce this and booting a production machine with lockdep would be problematic. Regards, Nikolay

[tip:locking/core] x86/cmpxchg, locking/atomics: Remove superfluous definitions

Commit-ID: 08645077b7f9f7824dbaf1959b0e014a894c8acc Gitweb: http://git.kernel.org/tip/08645077b7f9f7824dbaf1959b0e014a894c8acc Author: Nikolay Borisov <n.borisov.l...@gmail.com> AuthorDate: Mon, 26 Sep 2016 21:11:18 +0300 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:locking/core] x86/cmpxchg, locking/atomics: Remove superfluous definitions

Commit-ID: 08645077b7f9f7824dbaf1959b0e014a894c8acc Gitweb: http://git.kernel.org/tip/08645077b7f9f7824dbaf1959b0e014a894c8acc Author: Nikolay Borisov AuthorDate: Mon, 26 Sep 2016 21:11:18 +0300 Committer: Ingo Molnar CommitDate: Fri, 30 Sep 2016 10:56:01 +0200 x86/cmpxchg, locking

Re: [PATCH] Add ability to override kernel release check

On 09/29/2016 04:14 PM, Nikolay Borisov wrote: > From: Nikolay Borisov <n.bori...@siteground.com> > > In some situation it might be useful to disable checking the > kernel release. This happens when a kernel module is being rebuilt > and then probed. Without this overr

Re: [PATCH] Add ability to override kernel release check

On 09/29/2016 04:14 PM, Nikolay Borisov wrote: > From: Nikolay Borisov > > In some situation it might be useful to disable checking the > kernel release. This happens when a kernel module is being rebuilt > and then probed. Without this override one has to reboot the machine

[RFC PATCH] ipc/sem.c: Add cond_resched in exit_sme

block synchronize_rcu operations, which more or less de-stabilises the whole system. Fix this by introducing a cond_resched at the beginning of the loop. Signed-off-by: Nikolay Borisov <ker...@kyup.com> --- So this patch fixes the following: NMI watchdog: BUG: soft lockup - CPU#10 stuck f

[RFC PATCH] ipc/sem.c: Add cond_resched in exit_sme

block synchronize_rcu operations, which more or less de-stabilises the whole system. Fix this by introducing a cond_resched at the beginning of the loop. Signed-off-by: Nikolay Borisov --- So this patch fixes the following: NMI watchdog: BUG: soft lockup - CPU#10 stuck for 23s! [httpd:18119

[PATCH] Add ability to override kernel release check

From: Nikolay Borisov <n.bori...@siteground.com> In some situation it might be useful to disable checking the kernel release. This happens when a kernel module is being rebuilt and then probed. Without this override one has to reboot the machine with the new kernel (and module) and th

[PATCH] Add ability to override kernel release check

From: Nikolay Borisov In some situation it might be useful to disable checking the kernel release. This happens when a kernel module is being rebuilt and then probed. Without this override one has to reboot the machine with the new kernel (and module) and then use systemtap. To rectify

Re: kernel BUG at net/unix/garbage.c:149!"

t; of MSG_PEEK also. It is trivially correct, but I haven't tested it. > > Thanks, > Miklos > Dave, What's the status of https://patchwork.ozlabs.org/patch/664062/ , is this going to be picked up ? Regards, Nikolay

Re: kernel BUG at net/unix/garbage.c:149!"

ut I haven't tested it. > > Thanks, > Miklos > Dave, What's the status of https://patchwork.ozlabs.org/patch/664062/ , is this going to be picked up ? Regards, Nikolay

[PATCH] x86/cmpxchg: Remove superfluous definitions

cmpxchg contained definitions for unused (x)add_* operations, dating back to the original ticket spinlock implementation. Nowadays these are unused so remove them. Signed-off-by: Nikolay Borisov <n.borisov.l...@gmail.com> --- arch/x86/include/asm/cmpxchg.

[PATCH] x86/cmpxchg: Remove superfluous definitions

cmpxchg contained definitions for unused (x)add_* operations, dating back to the original ticket spinlock implementation. Nowadays these are unused so remove them. Signed-off-by: Nikolay Borisov --- arch/x86/include/asm/cmpxchg.h | 44 -- 1 file changed

Re: thousands of kworker processes with 4.7.x and 4.8-rc*

processes to see if they are all executing a parituclar piece of work. That might help you narrow down where they originate from. Cat multiple /proc/$kworker-pid/stack files and see if a pattern emerges. Regards, Nikolay > > > Tomasz Chmielewski > https://lxadm.com > >

Re: thousands of kworker processes with 4.7.x and 4.8-rc*

processes to see if they are all executing a parituclar piece of work. That might help you narrow down where they originate from. Cat multiple /proc/$kworker-pid/stack files and see if a pattern emerges. Regards, Nikolay > > > Tomasz Chmielewski > https://lxadm.com > >

Re: BUG_ON in rcu_sync_func triggered

On Wed, Sep 14, 2016 at 3:58 PM, Oleg Nesterov <o...@redhat.com> wrote: > On 09/14, Nikolay Borisov wrote: >> >> [ 557.006656] [] dump_stack+0x6b/0xa0 >> [ 557.012737] [] warn_slowpath_common+0x95/0xe0 >> [ 557.019781] [] warn_slowpath_null+0x1a/0x20 >

Re: BUG_ON in rcu_sync_func triggered

On Wed, Sep 14, 2016 at 3:58 PM, Oleg Nesterov wrote: > On 09/14, Nikolay Borisov wrote: >> >> [ 557.006656] [] dump_stack+0x6b/0xa0 >> [ 557.012737] [] warn_slowpath_common+0x95/0xe0 >> [ 557.019781] [] warn_slowpath_null+0x1a/0x20 >> [ 557.02664

Re: BUG_ON in rcu_sync_func triggered

On 09/13/2016 06:20 PM, Oleg Nesterov wrote: > On 09/13, Nikolay Borisov wrote: >> >> On 09/13/2016 05:35 PM, Nikolay Borisov wrote: >>> >>> On 09/13/2016 04:43 PM, Oleg Nesterov wrote: >>>> On 09/13, Oleg Nesterov wrote: >>>>> >

Re: BUG_ON in rcu_sync_func triggered

On 09/13/2016 06:20 PM, Oleg Nesterov wrote: > On 09/13, Nikolay Borisov wrote: >> >> On 09/13/2016 05:35 PM, Nikolay Borisov wrote: >>> >>> On 09/13/2016 04:43 PM, Oleg Nesterov wrote: >>>> On 09/13, Oleg Nesterov wrote: >>>>> >

Re: BUG_ON in rcu_sync_func triggered

On 09/13/2016 05:38 PM, Nikolay Borisov wrote: > > > On 09/13/2016 05:35 PM, Nikolay Borisov wrote: >> >> >> On 09/13/2016 04:43 PM, Oleg Nesterov wrote: >>> On 09/13, Oleg Nesterov wrote: >>>> >>>> OK... perhaps the unbal

Re: BUG_ON in rcu_sync_func triggered

On 09/13/2016 05:38 PM, Nikolay Borisov wrote: > > > On 09/13/2016 05:35 PM, Nikolay Borisov wrote: >> >> >> On 09/13/2016 04:43 PM, Oleg Nesterov wrote: >>> On 09/13, Oleg Nesterov wrote: >>>> >>>> OK... perhaps the unbal

Re: BUG_ON in rcu_sync_func triggered

On 09/13/2016 04:43 PM, Oleg Nesterov wrote: > On 09/13, Oleg Nesterov wrote: >> >> OK... perhaps the unbalanced up_write... I'll try to look at freeze/thaw >> code, > > Heh, yes, it looks racy or I am totally confused. > >> could test the debugging patch below meanwhile? > > Yes please.

Re: BUG_ON in rcu_sync_func triggered

On 09/13/2016 04:43 PM, Oleg Nesterov wrote: > On 09/13, Oleg Nesterov wrote: >> >> OK... perhaps the unbalanced up_write... I'll try to look at freeze/thaw >> code, > > Heh, yes, it looks racy or I am totally confused. > >> could test the debugging patch below meanwhile? > > Yes please.

Re: BUG_ON in rcu_sync_func triggered

On 09/13/2016 05:35 PM, Nikolay Borisov wrote: > > > On 09/13/2016 04:43 PM, Oleg Nesterov wrote: >> On 09/13, Oleg Nesterov wrote: >>> >>> OK... perhaps the unbalanced up_write... I'll try to look at freeze/thaw >>> code, >> >> Heh, yes

Re: BUG_ON in rcu_sync_func triggered

On 09/13/2016 05:35 PM, Nikolay Borisov wrote: > > > On 09/13/2016 04:43 PM, Oleg Nesterov wrote: >> On 09/13, Oleg Nesterov wrote: >>> >>> OK... perhaps the unbalanced up_write... I'll try to look at freeze/thaw >>> code, >> >> Heh, yes

Re: BUG_ON in rcu_sync_func triggered

On 09/12/2016 04:01 PM, Oleg Nesterov wrote: > Hi Nikolay, > [SNIP..] >> >> >> The bug on in question is this: BUG_ON(rsp->gp_state != GP_PASSED); >> >> Have you seen something like that before - the kernel is fairly old 4.4.2, > > No... than

Re: BUG_ON in rcu_sync_func triggered

On 09/12/2016 04:01 PM, Oleg Nesterov wrote: > Hi Nikolay, > [SNIP..] >> >> >> The bug on in question is this: BUG_ON(rsp->gp_state != GP_PASSED); >> >> Have you seen something like that before - the kernel is fairly old 4.4.2, > > No... than

Re: [PATCH] scripts: add ksymbolize.py

On 08/24/2016 07:40 PM, Tejun Heo wrote: > Hello, Alexander. > > On Wed, Aug 24, 2016 at 06:37:35PM +0200, Alexander Potapenko wrote: >> Commit the script that symbolizes BUG messages and KASAN error reports >> by adding file:line information to each stack frame. >> The script is a copy of >>

Re: [PATCH] scripts: add ksymbolize.py

On 08/24/2016 07:40 PM, Tejun Heo wrote: > Hello, Alexander. > > On Wed, Aug 24, 2016 at 06:37:35PM +0200, Alexander Potapenko wrote: >> Commit the script that symbolizes BUG messages and KASAN error reports >> by adding file:line information to each stack frame. >> The script is a copy of >>

Re: kernel BUG at net/unix/garbage.c:149!"

On 08/30/2016 12:18 PM, Miklos Szeredi wrote: > On Tue, Aug 30, 2016 at 12:37 AM, Miklos Szeredi wrote: >> On Sat, Aug 27, 2016 at 11:55 AM, Miklos Szeredi wrote: > >> crash> list -H gc_inflight_list unix_sock.link -s unix_sock.inflight | >> grep

Re: kernel BUG at net/unix/garbage.c:149!"

On 08/30/2016 12:18 PM, Miklos Szeredi wrote: > On Tue, Aug 30, 2016 at 12:37 AM, Miklos Szeredi wrote: >> On Sat, Aug 27, 2016 at 11:55 AM, Miklos Szeredi wrote: > >> crash> list -H gc_inflight_list unix_sock.link -s unix_sock.inflight | >> grep counter | cut -d= -f2 | awk '{s+=$1} END

Re: kernel BUG at net/unix/garbage.c:149!"

On Thu, Aug 25, 2016 at 12:40 AM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > On 24.08.2016 16:24, Nikolay Borisov wrote: [SNIP] > > One commit which could have to do with that is > > commit fc64869c48494a401b1fb627c9ecc4e6c1d74b0d > Author: Andrey Ryabinin

Re: kernel BUG at net/unix/garbage.c:149!"

On Thu, Aug 25, 2016 at 12:40 AM, Hannes Frederic Sowa wrote: > On 24.08.2016 16:24, Nikolay Borisov wrote: [SNIP] > > One commit which could have to do with that is > > commit fc64869c48494a401b1fb627c9ecc4e6c1d74b0d > Author: Andrey Ryabinin > Date: Wed May 18 19:19:27 2

kernel BUG at net/unix/garbage.c:149!"

ouched since it was introduced in 2007. So this must be a latent bug. This is the first time I've observed it. The state of the struct unix_sock can be found here http://sprunge.us/WCMW . Evidently, there are no inflight sockets. Regards, Nikolay

kernel BUG at net/unix/garbage.c:149!"

ouched since it was introduced in 2007. So this must be a latent bug. This is the first time I've observed it. The state of the struct unix_sock can be found here http://sprunge.us/WCMW . Evidently, there are no inflight sockets. Regards, Nikolay

Re: [PATCH tip/core/rcu 1/5] rcu: Fix soft lockup for rcu_nocb_kthread

On 22.08.2016 19:44, Paul E. McKenney wrote: > On Mon, Aug 22, 2016 at 07:19:53PM +0300, Nikolay Borisov wrote: >> >> [SNIP] >>> >>> Signed-off-by: Ding Tianhong <dingtianh...@huawei.com> >>> [ paulmck: Substituted cond_resched_rcu_qs for cond_re

Re: [PATCH tip/core/rcu 1/5] rcu: Fix soft lockup for rcu_nocb_kthread

On 22.08.2016 19:44, Paul E. McKenney wrote: > On Mon, Aug 22, 2016 at 07:19:53PM +0300, Nikolay Borisov wrote: >> >> [SNIP] >>> >>> Signed-off-by: Ding Tianhong >>> [ paulmck: Substituted cond_resched_rcu_qs for cond_resched. ] >> >> This

Re: [PATCH tip/core/rcu 1/5] rcu: Fix soft lockup for rcu_nocb_kthread

[SNIP] > > Signed-off-by: Ding Tianhong > [ paulmck: Substituted cond_resched_rcu_qs for cond_resched. ] This contradicts... > Signed-off-by: Paul E. McKenney > --- > kernel/rcu/tree_plugin.h | 1 + > 1 file changed, 1 insertion(+) > >

Re: [PATCH tip/core/rcu 1/5] rcu: Fix soft lockup for rcu_nocb_kthread

[SNIP] > > Signed-off-by: Ding Tianhong > [ paulmck: Substituted cond_resched_rcu_qs for cond_resched. ] This contradicts... > Signed-off-by: Paul E. McKenney > --- > kernel/rcu/tree_plugin.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/rcu/tree_plugin.h

Re: runaway latency detection

On 20.08.2016 20:03, T. Smith wrote: > The goal is to isolate causes of indeterminism when using the PREEMPT_RT > kernel configuration with full preemption and to characterize latency and > jitter using ftrace, any recommendations? What hardware is it ? If it's x86 it's entirely possible you

Re: runaway latency detection

On 20.08.2016 20:03, T. Smith wrote: > The goal is to isolate causes of indeterminism when using the PREEMPT_RT > kernel configuration with full preemption and to characterize latency and > jitter using ftrace, any recommendations? What hardware is it ? If it's x86 it's entirely possible you

Re: Strange behavior of perf top with PEBS

On 08/04/2016 06:29 PM, Jiri Olsa wrote: > On Tue, Jul 26, 2016 at 02:30:46PM +0300, Nikolay Borisov wrote: [SNIP] > > sorry for late response.. > > I checked on f22 kernel and it's missing the core2 PEBs fix: > 1424a09a9e18 perf/x86: fix PEBS issues on Intel Ato

Re: Strange behavior of perf top with PEBS

On 08/04/2016 06:29 PM, Jiri Olsa wrote: > On Tue, Jul 26, 2016 at 02:30:46PM +0300, Nikolay Borisov wrote: [SNIP] > > sorry for late response.. > > I checked on f22 kernel and it's missing the core2 PEBs fix: > 1424a09a9e18 perf/x86: fix PEBS issues on Intel Ato

Re: [PATCH v2] locks: Filter /proc/locks output on proc pid ns

On 08/03/2016 06:06 PM, J. Bruce Fields wrote: > Digging around... Oh, I see, there's an optional 'lock:..' line in > /proc/[pid]/fdinfo/[pid] file, is that what you're looking at? I'd > forgotten. Yeah, maybe that would make more sense long term. Yep, that's the one but this requires the

Re: [PATCH v2] locks: Filter /proc/locks output on proc pid ns

On 08/03/2016 06:06 PM, J. Bruce Fields wrote: > Digging around... Oh, I see, there's an optional 'lock:..' line in > /proc/[pid]/fdinfo/[pid] file, is that what you're looking at? I'd > forgotten. Yeah, maybe that would make more sense long term. Yep, that's the one but this requires the

Re: [PATCH v2] locks: Filter /proc/locks output on proc pid ns

On 08/03/2016 05:54 PM, Pavel Emelyanov wrote: > On 08/03/2016 05:17 PM, Nikolay Borisov wrote: >> >> [SNIP] >> >> [CCing some people from openvz/CRIU] > > Thanks :) > >> My train of thought was "we should have means which would be the one >

Re: [PATCH v2] locks: Filter /proc/locks output on proc pid ns

On 08/03/2016 05:54 PM, Pavel Emelyanov wrote: > On 08/03/2016 05:17 PM, Nikolay Borisov wrote: >> >> [SNIP] >> >> [CCing some people from openvz/CRIU] > > Thanks :) > >> My train of thought was "we should have means which would be the one >

Re: [PATCH v2] locks: Filter /proc/locks output on proc pid ns

On 08/03/2016 05:28 PM, J. Bruce Fields wrote: > On Wed, Aug 03, 2016 at 05:17:09PM +0300, Nikolay Borisov wrote: >> >> >> On 08/03/2016 04:46 PM, Jeff Layton wrote: >>> On Wed, 2016-08-03 at 10:35 +0300, Nikolay Borisov wrote: >>>> On busy conta

Re: [PATCH v2] locks: Filter /proc/locks output on proc pid ns

On 08/03/2016 05:28 PM, J. Bruce Fields wrote: > On Wed, Aug 03, 2016 at 05:17:09PM +0300, Nikolay Borisov wrote: >> >> >> On 08/03/2016 04:46 PM, Jeff Layton wrote: >>> On Wed, 2016-08-03 at 10:35 +0300, Nikolay Borisov wrote: >>>> On busy conta

Re: [PATCH v2] locks: Filter /proc/locks output on proc pid ns

On 08/03/2016 04:46 PM, Jeff Layton wrote: > On Wed, 2016-08-03 at 10:35 +0300, Nikolay Borisov wrote: >> On busy container servers reading /proc/locks shows all the locks >> created by all clients. This can cause large latency spikes. In my >> case I observed lsof taki

Re: [PATCH v2] locks: Filter /proc/locks output on proc pid ns

On 08/03/2016 04:46 PM, Jeff Layton wrote: > On Wed, 2016-08-03 at 10:35 +0300, Nikolay Borisov wrote: >> On busy container servers reading /proc/locks shows all the locks >> created by all clients. This can cause large latency spikes. In my >> case I observed lsof taki

[PATCH v2] locks: Filter /proc/locks output on proc pid ns

as the one the proc was mounted in. When reading /proc/locks from the init_pid_ns show everything. Signed-off-by: Nikolay Borisov <ker...@kyup.com> --- fs/locks.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/fs/locks.c b/fs/locks.c index ee1b15f6fc13..751673d7f7fc 100644 --- a/fs/l

[PATCH v2] locks: Filter /proc/locks output on proc pid ns

as the one the proc was mounted in. When reading /proc/locks from the init_pid_ns show everything. Signed-off-by: Nikolay Borisov --- fs/locks.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/fs/locks.c b/fs/locks.c index ee1b15f6fc13..751673d7f7fc 100644 --- a/fs/locks.c +++ b/fs/locks.c

Re: [RFC PATCH] locks: Show only file_locks created in the same pidns as current process

e...@fieldses.org> writes: >> > >> > > >> > > On Tue, Aug 02, 2016 at 11:00:39AM -0500, Eric W. Biederman wrote: >> > > > >> > > > > > > > Nikolay Borisov <ker...@kyup.com> writes: >> > > > >&g

Re: [RFC PATCH] locks: Show only file_locks created in the same pidns as current process

gt; > >> > > On Tue, Aug 02, 2016 at 11:00:39AM -0500, Eric W. Biederman wrote: >> > > > >> > > > > > > > Nikolay Borisov writes: >> > > > >> > > > > >> > > > > Currently when /proc/locks is re

Re: [RFC PATCH] locks: Show only file_locks created in the same pidns as current process

On 08/02/2016 06:05 PM, J. Bruce Fields wrote: > On Tue, Aug 02, 2016 at 05:42:23PM +0300, Nikolay Borisov wrote: >> Currently when /proc/locks is read it will show all the file locks >> which are currently created on the machine. On containers, hosted >> on busy servers

Re: [RFC PATCH] locks: Show only file_locks created in the same pidns as current process

On 08/02/2016 06:05 PM, J. Bruce Fields wrote: > On Tue, Aug 02, 2016 at 05:42:23PM +0300, Nikolay Borisov wrote: >> Currently when /proc/locks is read it will show all the file locks >> which are currently created on the machine. On containers, hosted >> on busy servers

[RFC PATCH] locks: Show only file_locks created in the same pidns as current process

of relevant entries. Fix it by filtering the locks listed by the pidns of the current process and the process which created the lock. Signed-off-by: Nikolay Borisov <ker...@kyup.com> --- fs/locks.c | 8 1 file changed, 8 insertions(+) diff --git a/fs/locks.c b/fs/locks.c

[RFC PATCH] locks: Show only file_locks created in the same pidns as current process

of relevant entries. Fix it by filtering the locks listed by the pidns of the current process and the process which created the lock. Signed-off-by: Nikolay Borisov --- fs/locks.c | 8 1 file changed, 8 insertions(+) diff --git a/fs/locks.c b/fs/locks.c index 6333263b7bc8..53e96df4c583

Re: [RFC PATCH] locks: Show only file_locks created in the same pidns as current process

On 08/02/2016 05:42 PM, Nikolay Borisov wrote: > Currently when /proc/locks is read it will show all the file locks > which are currently created on the machine. On containers, hosted > on busy servers this means that doing lsof can be very slow. I > observed up to 5 seconds stalls

Re: [RFC PATCH] locks: Show only file_locks created in the same pidns as current process

On 08/02/2016 05:42 PM, Nikolay Borisov wrote: > Currently when /proc/locks is read it will show all the file locks > which are currently created on the machine. On containers, hosted > on busy servers this means that doing lsof can be very slow. I > observed up to 5 seconds stalls

Re: Strange behavior of perf top with PEBS

On 07/20/2016 05:38 PM, Jiri Olsa wrote: > On Wed, Jul 20, 2016 at 04:34:17PM +0200, Jiri Olsa wrote: >> On Wed, Jul 20, 2016 at 04:28:34PM +0300, Nikolay Borisov wrote: >>> Hello, >>> >>> Running perf version 4.4.14.g0cb188d (no modification to the PMU/perf

Re: Strange behavior of perf top with PEBS

On 07/20/2016 05:38 PM, Jiri Olsa wrote: > On Wed, Jul 20, 2016 at 04:34:17PM +0200, Jiri Olsa wrote: >> On Wed, Jul 20, 2016 at 04:28:34PM +0300, Nikolay Borisov wrote: >>> Hello, >>> >>> Running perf version 4.4.14.g0cb188d (no modification to the PMU/perf

[PATCH v2] ceph: Mark the file cache as unreclaimable

this by removing the reclaimable flag for the file's cache. Signed-off-by: Nikolay Borisov <n.borisov.l...@gmail.com> --- Fixed checkpatch warning + missing SOB line fs/ceph/super.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ceph/super.c b/fs/ceph/super.c

[PATCH v2] ceph: Mark the file cache as unreclaimable

this by removing the reclaimable flag for the file's cache. Signed-off-by: Nikolay Borisov --- Fixed checkpatch warning + missing SOB line fs/ceph/super.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ceph/super.c b/fs/ceph/super.c index 91e02481ce06..8697cac6add0 100644

[PATCH] ceph: Mark the file cache as unreclaimable

Ceph creates multiple caches with the SLAB_RECLAIMABLE flag set, so that it can satisfy its internal needs. Inspecting the code shows that most of the caches are indeed reclaimable since they are directly related to the generic inode/dentry shrinkers. However, one of the cache used to satisfy

[PATCH] ceph: Mark the file cache as unreclaimable

Ceph creates multiple caches with the SLAB_RECLAIMABLE flag set, so that it can satisfy its internal needs. Inspecting the code shows that most of the caches are indeed reclaimable since they are directly related to the generic inode/dentry shrinkers. However, one of the cache used to satisfy

Re: Strange behavior of perf top with PEBS

On 07/20/2016 05:34 PM, Jiri Olsa wrote: > On Wed, Jul 20, 2016 at 04:28:34PM +0300, Nikolay Borisov wrote: >> Hello, >> >> Running perf version 4.4.14.g0cb188d (no modification to the PMU/perf >> code) I observed that "perf top" counts no cycles and produ

Re: Strange behavior of perf top with PEBS

On 07/20/2016 05:34 PM, Jiri Olsa wrote: > On Wed, Jul 20, 2016 at 04:28:34PM +0300, Nikolay Borisov wrote: >> Hello, >> >> Running perf version 4.4.14.g0cb188d (no modification to the PMU/perf >> code) I observed that "perf top" counts no cycles and produ

Strange behavior of perf top with PEBS

Hello, Running perf version 4.4.14.g0cb188d (no modification to the PMU/perf code) I observed that "perf top" counts no cycles and produces no output. After a bit of head scratching and testing I figured that running "perf top -e cycles" actually works whereas the default option is equivalent to

Strange behavior of perf top with PEBS

Hello, Running perf version 4.4.14.g0cb188d (no modification to the PMU/perf code) I observed that "perf top" counts no cycles and produces no output. After a bit of head scratching and testing I figured that running "perf top -e cycles" actually works whereas the default option is equivalent to

Re: [RFC PATCH] dcache: give a chance to yield in shrink_dentry_list

entries. Adding a simple cond_resched would give >> the cpu a chance to do some other useful work and no trip the >> softlockup watchdog. > > Hello Nikolay, > > I'm interested in your proposed patch because I believe I've come across > the same issue a handful of times, t

Re: [RFC PATCH] dcache: give a chance to yield in shrink_dentry_list

entries. Adding a simple cond_resched would give >> the cpu a chance to do some other useful work and no trip the >> softlockup watchdog. > > Hello Nikolay, > > I'm interested in your proposed patch because I believe I've come across > the same issue a handful of times, t

Re: [RFC PATCH 2/2] perf: Filter events based on perf-namespace

On 07/12/2016 02:47 PM, Peter Zijlstra wrote: > On Tue, Jul 12, 2016 at 02:56:17PM +0530, Aravinda Prasad wrote: >> >> >> On Monday 27 June 2016 09:20 PM, Peter Zijlstra wrote: >>> On Tue, Jun 14, 2016 at 10:19:51PM +0530, Aravinda Prasad wrote: Whenever perf tool is executed inside a

Re: [RFC PATCH 2/2] perf: Filter events based on perf-namespace

On 07/12/2016 02:47 PM, Peter Zijlstra wrote: > On Tue, Jul 12, 2016 at 02:56:17PM +0530, Aravinda Prasad wrote: >> >> >> On Monday 27 June 2016 09:20 PM, Peter Zijlstra wrote: >>> On Tue, Jun 14, 2016 at 10:19:51PM +0530, Aravinda Prasad wrote: Whenever perf tool is executed inside a

Re: [PATCH v2] kexec: Fix kdump failure with notsc

On 07/07/2016 01:17 PM, Wei Jiangang wrote: > If we specify the 'notsc' boot parameter for the dump-capture kernel, > and then trigger a crash(panic) by using "ALT-SysRq-c" or "echo c > > /proc/sysrq-trigger", > the dump-capture kernel will hang in calibrate_delay_converge(): > > /* wait

Re: [PATCH v2] kexec: Fix kdump failure with notsc

On 07/07/2016 01:17 PM, Wei Jiangang wrote: > If we specify the 'notsc' boot parameter for the dump-capture kernel, > and then trigger a crash(panic) by using "ALT-SysRq-c" or "echo c > > /proc/sysrq-trigger", > the dump-capture kernel will hang in calibrate_delay_converge(): > > /* wait

Re: [PATCH 4.4 00/32] 4.4.15-stable review

On 07/07/2016 04:19 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.15 release. > There are 32 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. Greg, I'd

Re: [PATCH 4.4 00/32] 4.4.15-stable review

On 07/07/2016 04:19 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.15 release. > There are 32 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. Greg, I'd

Re: [PATCH] btrfs: Fix slab accounting flags

After some days of inactivity a gentle ping is in order. On 06/23/2016 09:17 PM, Nikolay Borisov wrote: > BTRFS is using a variety of slab caches to satisfy internal needs. > Those slab caches are always allocated with the SLAB_RECLAIM_ACCOUNT, > meaning allocations from the caches

Re: [PATCH] btrfs: Fix slab accounting flags

After some days of inactivity a gentle ping is in order. On 06/23/2016 09:17 PM, Nikolay Borisov wrote: > BTRFS is using a variety of slab caches to satisfy internal needs. > Those slab caches are always allocated with the SLAB_RECLAIM_ACCOUNT, > meaning allocations from the caches

Re: [PATCH v3 0/4] sched,time: fix irq time accounting with nohz_idle

On 06/30/2016 10:35 PM, r...@redhat.com wrote: > Currently irq time accounting only works in these cases: > 1) purely ticke based accounting > 2) nohz_full accounting, but only on housekeeping & nohz_full CPUs > 3) architectures with native vtime accounting > > On nohz_idle CPUs, which are

Re: [PATCH v3 0/4] sched,time: fix irq time accounting with nohz_idle

On 06/30/2016 10:35 PM, r...@redhat.com wrote: > Currently irq time accounting only works in these cases: > 1) purely ticke based accounting > 2) nohz_full accounting, but only on housekeeping & nohz_full CPUs > 3) architectures with native vtime accounting > > On nohz_idle CPUs, which are

Re: GPF in __mark_inode_dirty due to locked_inode_to_wb_and_lock_list returning NULL

On 07/01/2016 08:38 PM, Tejun Heo wrote: > On Fri, Jul 01, 2016 at 12:00:50PM +0200, Jan Kara wrote: >> Hello, >> >> On Thu 30-06-16 14:18:14, Nikolay Borisov wrote: >>> In light of the discussion in https://patchwork.kernel.org/patch/9187411/ >>>

Re: GPF in __mark_inode_dirty due to locked_inode_to_wb_and_lock_list returning NULL

On 07/01/2016 08:38 PM, Tejun Heo wrote: > On Fri, Jul 01, 2016 at 12:00:50PM +0200, Jan Kara wrote: >> Hello, >> >> On Thu 30-06-16 14:18:14, Nikolay Borisov wrote: >>> In light of the discussion in https://patchwork.kernel.org/patch/9187411/ >>>

GPF in __mark_inode_dirty due to locked_inode_to_wb_and_lock_list returning NULL

sible to stem from the same issue discussed in the referenced email threads or is it a different, btrfs-specific problem. Regards, Nikolay

GPF in __mark_inode_dirty due to locked_inode_to_wb_and_lock_list returning NULL

sible to stem from the same issue discussed in the referenced email threads or is it a different, btrfs-specific problem. Regards, Nikolay

Re: Unbounded growth of slab caches and how to shrink them

On 06/29/2016 05:00 PM, Christoph Lameter wrote: > On Wed, 29 Jun 2016, Nikolay Borisov wrote: > >> I've observed a rather strange unbounded growth of the kmalloc-192 >> slab cache: >> >> OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME >> 711124

Re: Unbounded growth of slab caches and how to shrink them

On 06/29/2016 05:00 PM, Christoph Lameter wrote: > On Wed, 29 Jun 2016, Nikolay Borisov wrote: > >> I've observed a rather strange unbounded growth of the kmalloc-192 >> slab cache: >> >> OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME >> 711124

Unbounded growth of slab caches and how to shrink them

for anything other than satisfying memory allocation from this cache. Regards, Nikolay

Unbounded growth of slab caches and how to shrink them

for anything other than satisfying memory allocation from this cache. Regards, Nikolay

[PATCH] btrfs: Handle uninitialised inode eviction

ads to vfs calling into btrfs_evict_inode. This leads to null pointer dereference. To handle this situation check whether the passed inode has root set and just free it in case it doesn't. Signed-off-by: Nikolay Borisov <ker...@kyup.com> --- fs/btrfs/inode.c | 9 - 1 file changed, 8 i

[PATCH] btrfs: Handle uninitialised inode eviction

ads to vfs calling into btrfs_evict_inode. This leads to null pointer dereference. To handle this situation check whether the passed inode has root set and just free it in case it doesn't. Signed-off-by: Nikolay Borisov --- fs/btrfs/inode.c | 9 - 1 file changed, 8 insertions(+), 1 delet

Re: [RFC 00/12] lockdep: Implement crossrelease feature

On 06/24/2016 02:37 AM, Byungchul Park wrote: > On Mon, Jun 20, 2016 at 01:55:15PM +0900, Byungchul Park wrote: > > Hello, > > I have a plan to resend this patchset after reinforcement of > documentation. However I am wondering what you think about the > main concept of this. A main motivation

<    2   3   4   5   6   7   8   9   10   11   >