Re: [PATCH v3] cpuidle: poll_state: Add time limit to poll_idle()

On Wed, 2018-03-14 at 15:08 +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > If poll_idle() is allowed to spin until need_resched() returns > 'true', > it may actually spin for a much longer time than expected by the idle > governor, since

Re: [PATCH v3] cpuidle: poll_state: Add time limit to poll_idle()

On Wed, 2018-03-14 at 15:08 +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > If poll_idle() is allowed to spin until need_resched() returns > 'true', > it may actually spin for a much longer time than expected by the idle > governor, since set_tsk_need_resched() is not always called

Re: [PATCH v2] cpuidle: poll_state: Add time limit to poll_idle()

On Wed, 2018-03-14 at 13:04 +0100, Peter Zijlstra wrote: > On x86 we don't have to use that time_check_counter thing, > sched_clock() > is really cheap, not sure if it makes sense on other platforms. Are you sure? I saw a 5-10% increase in CPU use, for a constant query rate to a memcache style

Re: [PATCH v2] cpuidle: poll_state: Add time limit to poll_idle()

On Wed, 2018-03-14 at 13:04 +0100, Peter Zijlstra wrote: > On x86 we don't have to use that time_check_counter thing, > sched_clock() > is really cheap, not sure if it makes sense on other platforms. Are you sure? I saw a 5-10% increase in CPU use, for a constant query rate to a memcache style

Re: [RFT][PATCH v7 0/8] sched/cpuidle: Idle loop rework

On Wed, 2018-03-21 at 14:55 +0100, Rafael J. Wysocki wrote: > On Wednesday, March 21, 2018 1:31:07 PM CET Rik van Riel wrote: > > On Tue, 2018-03-20 at 16:12 +0100, Rafael J. Wysocki wrote: > > > Hi All, > > > > > > Thanks a lot for the feedback so far! >

Re: [RFT][PATCH v7 0/8] sched/cpuidle: Idle loop rework

On Wed, 2018-03-21 at 14:55 +0100, Rafael J. Wysocki wrote: > On Wednesday, March 21, 2018 1:31:07 PM CET Rik van Riel wrote: > > On Tue, 2018-03-20 at 16:12 +0100, Rafael J. Wysocki wrote: > > > Hi All, > > > > > > Thanks a lot for the feedback so far! >

Re: [RFT][PATCH v7 0/8] sched/cpuidle: Idle loop rework

On Tue, 2018-03-20 at 16:12 +0100, Rafael J. Wysocki wrote: > Hi All, > > Thanks a lot for the feedback so far! > > Respin after recent comments from Peter. > > Patches [1-3] unmodified since v5, patch 4 is new and the other ones > have been updated to address feedback. > > The previous

Re: [RFT][PATCH v7 0/8] sched/cpuidle: Idle loop rework

On Tue, 2018-03-20 at 16:12 +0100, Rafael J. Wysocki wrote: > Hi All, > > Thanks a lot for the feedback so far! > > Respin after recent comments from Peter. > > Patches [1-3] unmodified since v5, patch 4 is new and the other ones > have been updated to address feedback. > > The previous

Re: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework

On Fri, 2018-03-09 at 10:34 +0100, Rafael J. Wysocki wrote: > Hi All, > > Thanks a lot for the discussion and testing so far! > > This is a total respin of the whole series, so please look at it > afresh. > Patches 2 and 3 are the most similar to their previous versions, but > still they are

Re: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework

On Fri, 2018-03-09 at 10:34 +0100, Rafael J. Wysocki wrote: > Hi All, > > Thanks a lot for the discussion and testing so far! > > This is a total respin of the whole series, so please look at it > afresh. > Patches 2 and 3 are the most similar to their previous versions, but > still they are

Re: [RFC/RFT][PATCH v2 0/6] sched/cpuidle: Idle loop rework

On Thu, 2018-03-08 at 07:18 -0800, Doug Smythies wrote: > On 2018.03.07 17:29 Doug wrote: > > On 2018.03.07 14:12 Rafael J. Wysocki wrote: > > > On Wed, Mar 7, 2018 at 6:04 PM, Doug Smythies > > t> wrote: > > > > On 2018.03.06 12:57 Rafael J. Wysocki wrote: > > > > During the

Re: [RFC/RFT][PATCH v2 0/6] sched/cpuidle: Idle loop rework

On Thu, 2018-03-08 at 07:18 -0800, Doug Smythies wrote: > On 2018.03.07 17:29 Doug wrote: > > On 2018.03.07 14:12 Rafael J. Wysocki wrote: > > > On Wed, Mar 7, 2018 at 6:04 PM, Doug Smythies > > t> wrote: > > > > On 2018.03.06 12:57 Rafael J. Wysocki wrote: > > > > During the test I got some

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Sun, 2018-03-04 at 23:28 +0100, Rafael J. Wysocki wrote: > > +++ linux-pm/kernel/sched/idle.c > @@ -188,13 +188,14 @@ static void cpuidle_idle_call(void) > } else { > unsigned int duration_us; > > - tick_nohz_idle_go_idle(true); > -

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Sun, 2018-03-04 at 23:28 +0100, Rafael J. Wysocki wrote: > > +++ linux-pm/kernel/sched/idle.c > @@ -188,13 +188,14 @@ static void cpuidle_idle_call(void) > } else { > unsigned int duration_us; > > - tick_nohz_idle_go_idle(true); > -

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, 2018-03-05 at 13:35 +0100, Peter Zijlstra wrote: > On Sun, Mar 04, 2018 at 11:28:56PM +0100, Rafael J. Wysocki wrote: > > Index: linux-pm/kernel/sched/idle.c > > === > > --- linux-pm.orig/kernel/sched/idle.c > > +++

Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

On Mon, 2018-03-05 at 13:35 +0100, Peter Zijlstra wrote: > On Sun, Mar 04, 2018 at 11:28:56PM +0100, Rafael J. Wysocki wrote: > > Index: linux-pm/kernel/sched/idle.c > > === > > --- linux-pm.orig/kernel/sched/idle.c > > +++

Re: [PATCH] mm: memcontrol: fix NR_WRITEBACK leak in memcg and system stats

; Signed-off-by: Johannes Weiner <han...@cmpxchg.org> > Reviewed-by: Rik van Riel <r...@surriel.com> -- All Rights Reversed. signature.asc Description: This is a digitally signed message part

Re: [PATCH] mm: memcontrol: fix NR_WRITEBACK leak in memcg and system stats

nes Weiner > Reviewed-by: Rik van Riel -- All Rights Reversed. signature.asc Description: This is a digitally signed message part

Re: [PATCH] lockdep: Avoid triggering hardlockup from debug_show_all_locks()

ds > up waiting for tasklist_lock. > > Touch the NMI watchdog while printing the held locks to avoid > spuriously triggering the hardlockup detector. > > Signed-off-by: Tejun Heo <t...@kernel.org> On this patch: Acked-by: Rik van Riel <r...@surriel.com> However, it seems

Re: [PATCH] lockdep: Avoid triggering hardlockup from debug_show_all_locks()

ds > up waiting for tasklist_lock. > > Touch the NMI watchdog while printing the held locks to avoid > spuriously triggering the hardlockup detector. > > Signed-off-by: Tejun Heo On this patch: Acked-by: Rik van Riel However, it seems like we run into things like this on a fairly

Re: [PATCH -next] fork.c: Check error and return early

On Thu, 2017-11-16 at 22:28 -0200, Marcos Paulo de Souza wrote: > Thus reducing one indentation level while maintaining the same > rationale. > > Signed-off-by: Marcos Paulo de Souza <marcos.souza@gmail.com> Acked-by: Rik van Riel <r...@redhat.com>

Re: [PATCH -next] fork.c: Check error and return early

On Thu, 2017-11-16 at 22:28 -0200, Marcos Paulo de Souza wrote: > Thus reducing one indentation level while maintaining the same > rationale. > > Signed-off-by: Marcos Paulo de Souza Acked-by: Rik van Riel

Re: [PATCH 1/2] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On Thu, 2017-11-16 at 10:50 +0800, Quan Xu wrote: > > On 2017-11-15 22:43, Rik van Riel wrote: > > Can you explain why you believe that? > > for example, a vcpu thread is running in kvm mode under cretical > condition to stop. QEMU send an IPI to cause a VM-exit to

Re: [PATCH 1/2] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On Thu, 2017-11-16 at 10:50 +0800, Quan Xu wrote: > > On 2017-11-15 22:43, Rik van Riel wrote: > > Can you explain why you believe that? > > for example, a vcpu thread is running in kvm mode under cretical > condition to stop. QEMU send an IPI to cause a VM-exit to

Re: [PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On Wed, 2017-11-15 at 09:34 +0100, Paolo Bonzini wrote: > On 14/11/2017 20:40, David Hildenbrand wrote: > > I think we should check all get/put_fpu callers if they need > > preempt_disable(). > > > > E.g. em_fxrstor() needs disabled preemption as we temporarily > > save + restore some host

Re: [PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On Wed, 2017-11-15 at 09:34 +0100, Paolo Bonzini wrote: > On 14/11/2017 20:40, David Hildenbrand wrote: > > I think we should check all get/put_fpu callers if they need > > preempt_disable(). > > > > E.g. em_fxrstor() needs disabled preemption as we temporarily > > save + restore some host

Re: [PATCH 1/2] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On Wed, 2017-11-15 at 14:53 +0800, quan.x...@gmail.com wrote: > > On 2017/11/15 05:54, r...@redhat.com wrote: > > From: Rik van Riel <r...@redhat.com> > > > > Currently, every time a VCPU is scheduled out, the host kernel will > > first save the guest FP

Re: [PATCH 1/2] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On Wed, 2017-11-15 at 14:53 +0800, quan.x...@gmail.com wrote: > > On 2017/11/15 05:54, r...@redhat.com wrote: > > From: Rik van Riel > > > > Currently, every time a VCPU is scheduled out, the host kernel will > > first save the guest FPU/xstate context, then load

Re: [PATCH 1/2] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On Wed, 2017-11-15 at 12:33 +0800, Wanpeng Li wrote: > 2017-11-15 11:03 GMT+08:00 Rik van Riel <r...@redhat.com>: > > On Wed, 2017-11-15 at 08:47 +0800, Wanpeng Li wrote: > > > 2017-11-15 5:54 GMT+08:00  <r...@redhat.com>: > > > > From: Rik van Riel &l

Re: [PATCH 1/2] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On Wed, 2017-11-15 at 12:33 +0800, Wanpeng Li wrote: > 2017-11-15 11:03 GMT+08:00 Rik van Riel : > > On Wed, 2017-11-15 at 08:47 +0800, Wanpeng Li wrote: > > > 2017-11-15 5:54 GMT+08:00  : > > > > From: Rik van Riel > > > > > > > > Currentl

Re: [PATCH 1/2] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On Wed, 2017-11-15 at 08:47 +0800, Wanpeng Li wrote: > 2017-11-15 5:54 GMT+08:00  <r...@redhat.com>: > > From: Rik van Riel <r...@redhat.com> > > > > Currently, every time a VCPU is scheduled out, the host kernel will > > first save the guest FPU/xstate co

Re: [PATCH 1/2] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On Wed, 2017-11-15 at 08:47 +0800, Wanpeng Li wrote: > 2017-11-15 5:54 GMT+08:00  : > > From: Rik van Riel > > > > Currently, every time a VCPU is scheduled out, the host kernel will > > first save the guest FPU/xstate context, then load the qemu > >

Re: [PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On Tue, 2017-11-14 at 20:40 +0100, David Hildenbrand wrote: > On 14.11.2017 19:07, Rik van Riel wrote: > > On Tue, 2017-11-14 at 17:57 +0100, David Hildenbrand wrote: > > > > > > > diff --git a/arch/x86/include/asm/kvm_host.h > > > > b/arch/x86/include

Re: [PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On Tue, 2017-11-14 at 20:40 +0100, David Hildenbrand wrote: > On 14.11.2017 19:07, Rik van Riel wrote: > > On Tue, 2017-11-14 at 17:57 +0100, David Hildenbrand wrote: > > > > > > > diff --git a/arch/x86/include/asm/kvm_host.h > > > > b/arch/x86/include

Re: [PATCH 04/30] x86, kaiser: disable global pages by default with KAISER

On Fri, 2017-11-10 at 11:31 -0800, Dave Hansen wrote: > From: Dave Hansen > > Global pages stay in the TLB across context switches.  Since all > contexts > share the same kernel mapping, these mappings are marked as global > pages > so kernel entries in the TLB are

Re: [PATCH 04/30] x86, kaiser: disable global pages by default with KAISER

On Fri, 2017-11-10 at 11:31 -0800, Dave Hansen wrote: > From: Dave Hansen > > Global pages stay in the TLB across context switches.  Since all > contexts > share the same kernel mapping, these mappings are marked as global > pages > so kernel entries in the TLB are not flushed out on a context

Re: [PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On Tue, 2017-11-14 at 17:57 +0100, David Hildenbrand wrote: > > > diff --git a/arch/x86/include/asm/kvm_host.h > > b/arch/x86/include/asm/kvm_host.h > > index c73e493adf07..92e66685249e 100644 > > --- a/arch/x86/include/asm/kvm_host.h > > +++ b/arch/x86/include/asm/kvm_host.h > > We should also

Re: [PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On Tue, 2017-11-14 at 17:57 +0100, David Hildenbrand wrote: > > > diff --git a/arch/x86/include/asm/kvm_host.h > > b/arch/x86/include/asm/kvm_host.h > > index c73e493adf07..92e66685249e 100644 > > --- a/arch/x86/include/asm/kvm_host.h > > +++ b/arch/x86/include/asm/kvm_host.h > > We should also

[PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu_run

load is on the order of 0.1us, while ping-ponging between CPUs is on the order of 20us, and somewhat noisy. There may be other tests where performance changes are noticeable. Signed-off-by: Rik van Riel <r...@redhat.com> Suggested-by: Christian Borntraeger <borntrae...@de.ibm.com> -

[PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu_run

load is on the order of 0.1us, while ping-ponging between CPUs is on the order of 20us, and somewhat noisy. There may be other tests where performance changes are noticeable. Signed-off-by: Rik van Riel Suggested-by: Christian Borntraeger --- arch/x86/include/asm/kvm_host.h | 13

Re: [RFC 2/2] KVM: add virtio-pmem driver

On Thu, 2017-10-12 at 18:18 -0400, Pankaj Gupta wrote: > > > > On Thu, Oct 12, 2017 at 2:25 PM, Pankaj Gupta > > wrote: > > > > > > > >   This patch adds virtio-pmem driver for KVM guest. > > > > >   Guest reads the persistent memory range information > > > > >   over virtio

Re: [RFC 2/2] KVM: add virtio-pmem driver

On Thu, 2017-10-12 at 18:18 -0400, Pankaj Gupta wrote: > > > > On Thu, Oct 12, 2017 at 2:25 PM, Pankaj Gupta > > wrote: > > > > > > > >   This patch adds virtio-pmem driver for KVM guest. > > > > >   Guest reads the persistent memory range information > > > > >   over virtio bus from Qemu and

Re: [PATCH v6 1/2] pid: Replace pid bitmap implementation with IDR API

On Wed, 2017-10-11 at 15:37 -0700, Andrew Morton wrote: > On Wed, 11 Oct 2017 18:19:38 -0400 Gargi Sharma > wrote: > > > This patch replaces the current bitmap implemetation for > > Process ID allocation. Functions that are no longer required, > > for example, free_pidmap(),

Re: [PATCH v6 1/2] pid: Replace pid bitmap implementation with IDR API

On Wed, 2017-10-11 at 15:37 -0700, Andrew Morton wrote: > On Wed, 11 Oct 2017 18:19:38 -0400 Gargi Sharma > wrote: > > > This patch replaces the current bitmap implemetation for > > Process ID allocation. Functions that are no longer required, > > for example, free_pidmap(), alloc_pidmap(), etc.

Re: [PATCH v6 2/2] pid: Remove pidhash

ions(-) Fingers crossed for IA64. It all looks good, though. Reviewed-by: Rik van Riel <r...@redhat.com> -- All Rights Reversed. signature.asc Description: This is a digitally signed message part

Re: [PATCH v6 2/2] pid: Remove pidhash

t;  init/main.c|  1 - >  kernel/fork.c  |  2 +- >  kernel/pid.c   | 48 +--- > -- >  kernel/pid_namespace.c |  6 +++--- >  8 files changed, 18 insertions(+), 50 deletions(-) Fingers crossed for

Re: [PATCH v6 1/2] pid: Replace pid bitmap implementation with IDR API

-- >  6 files changed, 57 insertions(+), 208 deletions(-) I'm all out of nitpicks now :) Also, I really love that diffstat. Reviewed-by: Rik van Riel <r...@redhat.com> -- All Rights Reversed. signature.asc Description: This is a digitally signed message part

Re: [PATCH v6 1/2] pid: Replace pid bitmap implementation with IDR API

ed, 57 insertions(+), 208 deletions(-) I'm all out of nitpicks now :) Also, I really love that diffstat. Reviewed-by: Rik van Riel -- All Rights Reversed. signature.asc Description: This is a digitally signed message part

Re: [PATCH v4 2/2] pid: Remove pidhash

On Wed, 2017-10-11 at 17:47 +0800, kbuild test robot wrote: > > > '__compiletime_assert_33' declared with attribute error: > > > BUILD_BUG_ON failed: sizeof(struct upid) != 32 > >  _compiletime_assert(condition, msg, __compiletime_assert_, > __LINE__) >    

Re: [PATCH v4 2/2] pid: Remove pidhash

On Wed, 2017-10-11 at 17:47 +0800, kbuild test robot wrote: > > > '__compiletime_assert_33' declared with attribute error: > > > BUILD_BUG_ON failed: sizeof(struct upid) != 32 > >  _compiletime_assert(condition, msg, __compiletime_assert_, > __LINE__) >    

Re: [PATCH v5 1/2] pid: Replace pid bitmap implementation with IDR API

On Tue, 2017-10-10 at 19:22 -0400, Gargi Sharma wrote: > This patch replaces the current bitmap implemetation for > Process ID allocation. Functions that are no longer required, > for example, free_pidmap(), alloc_pidmap(), etc. are removed. > The rest of the functions are modified to use the IDR

Re: [PATCH v5 1/2] pid: Replace pid bitmap implementation with IDR API

On Tue, 2017-10-10 at 19:22 -0400, Gargi Sharma wrote: > This patch replaces the current bitmap implemetation for > Process ID allocation. Functions that are no longer required, > for example, free_pidmap(), alloc_pidmap(), etc. are removed. > The rest of the functions are modified to use the IDR

Re: [PATCH v4 1/2] pid: Replace pid bitmap implementation with IDR API

On Tue, 2017-10-10 at 17:11 +0100, Gargi Sharma wrote: > > I have listed down the code for both idr_for_each and > idr_for_each_entry. > IMHO idr_for_each_entry is easier to read, but YMMV. :) > > void kill_task(int id, void *ptr, void *data) > { > struct *pid = ptr; > struct task_struct

Re: [PATCH v4 1/2] pid: Replace pid bitmap implementation with IDR API

On Tue, 2017-10-10 at 17:11 +0100, Gargi Sharma wrote: > > I have listed down the code for both idr_for_each and > idr_for_each_entry. > IMHO idr_for_each_entry is easier to read, but YMMV. :) > > void kill_task(int id, void *ptr, void *data) > { > struct *pid = ptr; > struct task_struct

Re: [PATCH v4 1/2] pid: Replace pid bitmap implementation with IDR API

On Tue, 2017-10-10 at 13:35 +0100, Gargi Sharma wrote: > On Tue, Oct 10, 2017 at 12:50 PM, Oleg Nesterov > wrote: > > On 10/09, Andrew Morton wrote: > > > > > > > @@ -240,17 +230,11 @@ void zap_pid_ns_processes(struct > > > > pid_namespace *pid_ns) > > > >  * > > > >  */

Re: [PATCH v4 1/2] pid: Replace pid bitmap implementation with IDR API

On Tue, 2017-10-10 at 13:35 +0100, Gargi Sharma wrote: > On Tue, Oct 10, 2017 at 12:50 PM, Oleg Nesterov > wrote: > > On 10/09, Andrew Morton wrote: > > > > > > > @@ -240,17 +230,11 @@ void zap_pid_ns_processes(struct > > > > pid_namespace *pid_ns) > > > >  * > > > >  */ > > > >

Re: [PATCH 1/1] sched/cputime: do not decrease steal time after live migration on xen

On Tue, 2017-10-10 at 14:48 +0200, Peter Zijlstra wrote: > On Tue, Oct 10, 2017 at 02:42:01PM +0200, Stanislaw Gruszka wrote: > > > > + u64 steal, steal_time; > > > > + s64 steal_delta; > > > > + > > > > + steal_time = > > > >

Re: [PATCH 1/1] sched/cputime: do not decrease steal time after live migration on xen

On Tue, 2017-10-10 at 14:48 +0200, Peter Zijlstra wrote: > On Tue, Oct 10, 2017 at 02:42:01PM +0200, Stanislaw Gruszka wrote: > > > > + u64 steal, steal_time; > > > > + s64 steal_delta; > > > > + > > > > + steal_time = > > > >

Re: [PATCH v4 1/2] pid: Replace pid bitmap implementation with IDR API

On Tue, 2017-10-10 at 13:50 +0200, Oleg Nesterov wrote: > On 10/09, Andrew Morton wrote: > > > > > @@ -240,17 +230,11 @@ void zap_pid_ns_processes(struct > > > pid_namespace *pid_ns) > > >    * > > >    */ > > >   read_lock(_lock); > > > - nr = next_pidmap(pid_ns, 1); > > > - while (nr > 0) { > >

Re: [PATCH v4 1/2] pid: Replace pid bitmap implementation with IDR API

On Tue, 2017-10-10 at 13:50 +0200, Oleg Nesterov wrote: > On 10/09, Andrew Morton wrote: > > > > > @@ -240,17 +230,11 @@ void zap_pid_ns_processes(struct > > > pid_namespace *pid_ns) > > >    * > > >    */ > > >   read_lock(_lock); > > > - nr = next_pidmap(pid_ns, 1); > > > - while (nr > 0) { > >

Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation

On Mon, 2017-10-09 at 21:06 +0200, Michael Kerrisk (man-pages) wrote: > Hi Rik, > > I have a follow-up question re wipe-on-fork. What are the semantics > for this setting with respect to fork() and exec()? That is, in the > child of a fork(), does the flag remain set for the specified address >

Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation

On Mon, 2017-10-09 at 21:06 +0200, Michael Kerrisk (man-pages) wrote: > Hi Rik, > > I have a follow-up question re wipe-on-fork. What are the semantics > for this setting with respect to fork() and exec()? That is, in the > child of a fork(), does the flag remain set for the specified address >

Re: [PATCH v3 1/2] pid: Replace pid bitmap implementation with IDR API

/* Make the PID visible to find_pid_ns. */ > + idr_replace(>ns->idr, pid, upid->nr); >   upid->ns->nr_hashed++; >   } >   spin_unlock_irq(_lock); > Everything else looks great to me. Reviewed-by: Rik van Riel <r...@redhat.com> -- All Rights Reversed. signature.asc Description: This is a digitally signed message part

Re: [PATCH v3 1/2] pid: Replace pid bitmap implementation with IDR API

/* Make the PID visible to find_pid_ns. */ > + idr_replace(>ns->idr, pid, upid->nr); >   upid->ns->nr_hashed++; >   } >   spin_unlock_irq(_lock); > Everything else looks great to me. Reviewed-by: Rik van Riel -- All Rights Reversed. signature.asc Description: This is a digitally signed message part

Re: sysbench throughput degradation in 4.13+

On Wed, 2017-10-04 at 18:18 +0200, Peter Zijlstra wrote: > On Tue, Oct 03, 2017 at 10:39:32AM +0200, Peter Zijlstra wrote: > > So I was waiting for Rik, who promised to run a bunch of NUMA > > workloads > > over the weekend. > > > > The trivial thing regresses a wee bit on the overloaded case,

Re: sysbench throughput degradation in 4.13+

On Wed, 2017-10-04 at 18:18 +0200, Peter Zijlstra wrote: > On Tue, Oct 03, 2017 at 10:39:32AM +0200, Peter Zijlstra wrote: > > So I was waiting for Rik, who promised to run a bunch of NUMA > > workloads > > over the weekend. > > > > The trivial thing regresses a wee bit on the overloaded case,

Re: [PATCHv3] mm: Account pud page tables

to PUD level. > > Signed-off-by: Kirill A. Shutemov <kirill.shute...@linux.intel.com> > Cc: Michal Hocko <mho...@suse.com> > Cc: Vlastimil Babka <vba...@suse.cz> > Acked-by: Rik van Riel <r...@redhat.com> -- All rights reversed signature.asc Description: This is a digitally signed message part

Re: [PATCHv3] mm: Account pud page tables

to PUD level. > > Signed-off-by: Kirill A. Shutemov > Cc: Michal Hocko > Cc: Vlastimil Babka > Acked-by: Rik van Riel -- All rights reversed signature.asc Description: This is a digitally signed message part

Re: sysbench throughput degradation in 4.13+

On Tue, 2017-10-03 at 10:39 +0200, Peter Zijlstra wrote: > On Mon, Oct 02, 2017 at 11:53:12PM +0100, Matt Fleming wrote: > > On Wed, 27 Sep, at 01:58:20PM, Rik van Riel wrote: > > > > > > I like the simplicity of your approach!  I hope it does not break > > >

Re: sysbench throughput degradation in 4.13+

On Tue, 2017-10-03 at 10:39 +0200, Peter Zijlstra wrote: > On Mon, Oct 02, 2017 at 11:53:12PM +0100, Matt Fleming wrote: > > On Wed, 27 Sep, at 01:58:20PM, Rik van Riel wrote: > > > > > > I like the simplicity of your approach!  I hope it does not break > > >

Re: [PATCH] mm: remove unused pgdat->inactive_ratio

gt; Remove it. > > Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Reviewed-by: Rik van Riel <r...@redhat.com> -- All rights reversed signature.asc Description: This is a digitally signed message part

Re: [PATCH] mm: remove unused pgdat->inactive_ratio

gt; Remove it. > > Signed-off-by: Andrey Ryabinin Reviewed-by: Rik van Riel -- All rights reversed signature.asc Description: This is a digitally signed message part

Re: [PATCH v2 2/2] pid: Remove pidhash

On Mon, 2017-10-02 at 17:21 +0200, Oleg Nesterov wrote: > Hi Rik, > > On 10/02, Rik van Riel wrote: > > > > Gargi and I are looking at that code, and trying to figure out > > exactly what needs to be done to make all of this correct. > > see another email I sen

Re: [PATCH v2 2/2] pid: Remove pidhash

On Mon, 2017-10-02 at 17:21 +0200, Oleg Nesterov wrote: > Hi Rik, > > On 10/02, Rik van Riel wrote: > > > > Gargi and I are looking at that code, and trying to figure out > > exactly what needs to be done to make all of this correct. > > see another email I sen

Re: [PATCH v2 2/2] pid: Remove pidhash

On Mon, 2017-10-02 at 09:35 -0400, Rik van Riel wrote: > On Wed, 2017-09-27 at 17:45 +0200, Oleg Nesterov wrote: > > On 09/27, Gargi Sharma wrote: > > > > > > -#define find_next_offset(map, off) > > > > > > \ &

Re: [PATCH v2 2/2] pid: Remove pidhash

On Mon, 2017-10-02 at 09:35 -0400, Rik van Riel wrote: > On Wed, 2017-09-27 at 17:45 +0200, Oleg Nesterov wrote: > > On 09/27, Gargi Sharma wrote: > > > > > > -#define find_next_offset(map, off) > > > > > > \ &

Re: [PATCH v2 2/2] pid: Remove pidhash

On Wed, 2017-09-27 at 17:45 +0200, Oleg Nesterov wrote: > On 09/27, Gargi Sharma wrote: > > > > -#define find_next_offset(map, off) > > \ > > - find_next_zero_bit((map)->page, BITS_PER_PAGE, > > off) > > - > > this should go into the previous patch, but

Re: [PATCH v2 2/2] pid: Remove pidhash

On Wed, 2017-09-27 at 17:45 +0200, Oleg Nesterov wrote: > On 09/27, Gargi Sharma wrote: > > > > -#define find_next_offset(map, off) > > \ > > - find_next_zero_bit((map)->page, BITS_PER_PAGE, > > off) > > - > > this should go into the previous patch, but

Re: [PATCH v2 1/2] pid: Replace pid bitmap implementation with IDR API

On Sun, 2017-10-01 at 16:05 +0530, Gargi Sharma wrote: > On Sun, Oct 1, 2017 at 2:45 PM, Christoph Hellwig > wrote: > > > - task_active_pid_ns(current)->last_pid); > > > + task_active_pid_ns(current)->idr.idr_next-1); > > > > I think we want a well

Re: [PATCH v2 1/2] pid: Replace pid bitmap implementation with IDR API

On Sun, 2017-10-01 at 16:05 +0530, Gargi Sharma wrote: > On Sun, Oct 1, 2017 at 2:45 PM, Christoph Hellwig > wrote: > > > - task_active_pid_ns(current)->last_pid); > > > + task_active_pid_ns(current)->idr.idr_next-1); > > > > I think we want a well documented helper for

Re: [PATCH v2 1/2] pid: Replace pid bitmap implementation with IDR API

On Sun, 2017-10-01 at 02:15 -0700, Christoph Hellwig wrote: > > - task_active_pid_ns(current)->last_pid); > > + task_active_pid_ns(current)->idr.idr_next-1); > > I think we want a well documented helper for this pattern instead > of poking into the internals. > > Also is last

Re: [PATCH v2 1/2] pid: Replace pid bitmap implementation with IDR API

On Sun, 2017-10-01 at 02:15 -0700, Christoph Hellwig wrote: > > - task_active_pid_ns(current)->last_pid); > > + task_active_pid_ns(current)->idr.idr_next-1); > > I think we want a well documented helper for this pattern instead > of poking into the internals. > > Also is last

Re: [PATCH v2 0/2] Replace PID bitmap allocation with IDR API

On Fri, 2017-09-29 at 01:35 +0530, Gargi Sharma wrote: > On Thu, Sep 28, 2017 at 3:46 PM, Rik van Riel <r...@surriel.com> > wrote: > > On Fri, 2017-09-29 at 01:09 +0530, Gargi Sharma wrote: > > > > > 1000 processes that just sleep and sit around without doin

Re: [PATCH v2 0/2] Replace PID bitmap allocation with IDR API

On Fri, 2017-09-29 at 01:35 +0530, Gargi Sharma wrote: > On Thu, Sep 28, 2017 at 3:46 PM, Rik van Riel > wrote: > > On Fri, 2017-09-29 at 01:09 +0530, Gargi Sharma wrote: > > > > > 1000 processes that just sleep and sit around without doing > > > any

Re: [PATCH v2 0/2] Replace PID bitmap allocation with IDR API

On Fri, 2017-09-29 at 01:09 +0530, Gargi Sharma wrote: > 1000 processes that just sleep and sit around without doing > anything(100 second sleep and then exit). > > pstree with 10,000 processes > real    0m0.859s > user    0m0.536s > sys    0m0.172s > > ps with 10,000 processes > real    

Re: [PATCH v2 0/2] Replace PID bitmap allocation with IDR API

On Fri, 2017-09-29 at 01:09 +0530, Gargi Sharma wrote: > 1000 processes that just sleep and sit around without doing > anything(100 second sleep and then exit). > > pstree with 10,000 processes > real    0m0.859s > user    0m0.536s > sys    0m0.172s > > ps with 10,000 processes > real    

Re: sysbench throughput degradation in 4.13+

ximum load of the destination LLC, similar to how source_load and target_load work for regular migration. Also, get rid of an overly optimistic test that could potentially pull across a lot of tasks if the target LLC happened to have fewer runnable tasks at load balancing time. Conversely, sync wa

Re: sysbench throughput degradation in 4.13+

on LLC, similar to how source_load and target_load work for regular migration. Also, get rid of an overly optimistic test that could potentially pull across a lot of tasks if the target LLC happened to have fewer runnable tasks at load balancing time. Conversely, sync wakeups

Re: [PATCH v2 1/2] pid: Replace pid bitmap implementation with IDR API

On Wed, 2017-09-27 at 01:06 -0400, Gargi Sharma wrote: > This patch replaces the current bitmap implemetation for > Process ID allocation. Functions that are no longer required, > for example, free_pidmap(), alloc_pidmap(), etc. are removed. > The rest of the functions are modified to use the IDR

Re: [PATCH v2 1/2] pid: Replace pid bitmap implementation with IDR API

On Wed, 2017-09-27 at 01:06 -0400, Gargi Sharma wrote: > This patch replaces the current bitmap implemetation for > Process ID allocation. Functions that are no longer required, > for example, free_pidmap(), alloc_pidmap(), etc. are removed. > The rest of the functions are modified to use the IDR

[tip:x86/fpu] x86/fpu: Add FPU state copying quirk to handle XRSTOR failure on Intel Skylake CPUs

Commit-ID: 0852b374173bb57f870d78e6c6839c77b339be5f Gitweb: http://git.kernel.org/tip/0852b374173bb57f870d78e6c6839c77b339be5f Author: Rik van Riel <r...@redhat.com> AuthorDate: Sat, 23 Sep 2017 15:00:04 +0200 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sun, 24 Se

[tip:x86/fpu] x86/fpu: Add FPU state copying quirk to handle XRSTOR failure on Intel Skylake CPUs

Commit-ID: 0852b374173bb57f870d78e6c6839c77b339be5f Gitweb: http://git.kernel.org/tip/0852b374173bb57f870d78e6c6839c77b339be5f Author: Rik van Riel AuthorDate: Sat, 23 Sep 2017 15:00:04 +0200 Committer: Ingo Molnar CommitDate: Sun, 24 Sep 2017 13:04:34 +0200 x86/fpu: Add FPU state

Re: [PATCH 3/4] pid.c: Replace pidhash lookup with idr_get()

On Mon, 2017-09-25 at 23:14 +0530, Gargi Sharma wrote: > On Mon, Sep 25, 2017 at 6:50 PM, Rik van Riel <r...@surriel.com> > wrote: > > On Mon, 2017-09-25 at 08:56 -0400, Gargi Sharma wrote: > > > pidhash is no longer required as all the functionalities > > > ar

Re: [PATCH 3/4] pid.c: Replace pidhash lookup with idr_get()

On Mon, 2017-09-25 at 23:14 +0530, Gargi Sharma wrote: > On Mon, Sep 25, 2017 at 6:50 PM, Rik van Riel > wrote: > > On Mon, 2017-09-25 at 08:56 -0400, Gargi Sharma wrote: > > > pidhash is no longer required as all the functionalities > > > are present in the idr tree

Re: [PATCH 4/4] pid: Remove pidhash

ocated = PIDNS_HASH_ADDING, >   .level = 0, >   .child_reaper = _task, >   .user_ns = _user_ns, > Should PIDNS_HASH_ADDING be renamed too, now that the pidhash is gone? Not that I have any ideas for a better name. This patch looks good to me. Feel free to add this line the

Re: [PATCH 4/4] pid: Remove pidhash

IDNS_HASH_ADDING, >   .level = 0, >   .child_reaper = _task, >   .user_ns = _user_ns, > Should PIDNS_HASH_ADDING be renamed too, now that the pidhash is gone? Not that I have any ideas for a better name. This patch looks good to me. Feel free to add this line the next time you submit

Re: [PATCH 3/4] pid.c: Replace pidhash lookup with idr_get()

On Mon, 2017-09-25 at 08:56 -0400, Gargi Sharma wrote: > pidhash is no longer required as all the functionalities > are present in the idr tree associated with the namespace. > nr can be looked up in the namespace by idr_get(). > > Signed-off-by: Gargi Sharma > --- >  

Re: [PATCH 3/4] pid.c: Replace pidhash lookup with idr_get()

On Mon, 2017-09-25 at 08:56 -0400, Gargi Sharma wrote: > pidhash is no longer required as all the functionalities > are present in the idr tree associated with the namespace. > nr can be looked up in the namespace by idr_get(). > > Signed-off-by: Gargi Sharma > --- >  kernel/pid.c | 10

Re: [PATCH 2/4] idr: Add a function idr_get()

On Mon, 2017-09-25 at 08:56 -0400, Gargi Sharma wrote: > idr_get(namespace, id) returns a NULL if id is not present > in the idr tree or returns the pointer to the struct if id is > present in the idr tree. With this function in the idr library, > code for pid allocation can be simplified by

Re: [PATCH 2/4] idr: Add a function idr_get()

On Mon, 2017-09-25 at 08:56 -0400, Gargi Sharma wrote: > idr_get(namespace, id) returns a NULL if id is not present > in the idr tree or returns the pointer to the struct if id is > present in the idr tree. With this function in the idr library, > code for pid allocation can be simplified by

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