Re: [RFC PATCH 3/4] kvm: Add guest side support for free memory hints

On Thu, 07 Feb 2019 10:44:11 -0800 Alexander Duyck wrote: > On Thu, 2019-02-07 at 13:21 -0500, Luiz Capitulino wrote: > > On Mon, 04 Feb 2019 10:15:52 -0800 > > Alexander Duyck wrote: > > > > > From: Alexander Duyck > > > > > > Add guest su

Re: [RFC PATCH 3/4] kvm: Add guest side support for free memory hints

On Mon, 04 Feb 2019 10:15:52 -0800 Alexander Duyck wrote: > From: Alexander Duyck > > Add guest support for providing free memory hints to the KVM hypervisor for > freed pages huge TLB size or larger. I am restricting the size to > huge TLB order and larger because the hypercalls are too

Re: [RFC][Patch v8 5/7] virtio: Enables to add a single descriptor to the host

On Wed, 6 Feb 2019 08:24:14 -0500 Nitesh Narayan Lal wrote: > On 2/6/19 8:15 AM, Luiz Capitulino wrote: > > On Wed, 6 Feb 2019 07:56:37 -0500 > > Nitesh Narayan Lal wrote: > > > >> On 2/5/19 3:49 PM, Michael S. Tsirkin wrote: > >>> On Mon, Feb 04

Re: [RFC][Patch v8 5/7] virtio: Enables to add a single descriptor to the host

On Wed, 6 Feb 2019 07:56:37 -0500 Nitesh Narayan Lal wrote: > On 2/5/19 3:49 PM, Michael S. Tsirkin wrote: > > On Mon, Feb 04, 2019 at 03:18:52PM -0500, Nitesh Narayan Lal wrote: > >> This patch enables the caller to expose a single buffers to the > >> other end using vring descriptor. It also

Re: [PATCH] KVM: VMX: re-add ple_gap module parameter

On Wed, 28 Nov 2018 15:57:53 + "Moger, Babu" wrote: > My bad.. Sorry about this. I think this should also go to > sta...@vger.kernel.org No problem man, this happens. Thanks for the review! > > > -Original Message- > > From: Luiz Capitulino > &g

Re: [PATCH] KVM: VMX: re-add ple_gap module parameter

On Wed, 28 Nov 2018 15:57:53 + "Moger, Babu" wrote: > My bad.. Sorry about this. I think this should also go to > sta...@vger.kernel.org No problem man, this happens. Thanks for the review! > > > -Original Message- > > From: Luiz Capitulino > &g

Re: [PATCH] KVM: VMX: re-add ple_gap module parameter

On Fri, 23 Nov 2018 19:42:53 +0200 Liran Alon wrote: > > On 23 Nov 2018, at 19:02, Luiz Capitulino wrote: > > > > > > Apparently, the ple_gap parameter was accidentally removed > > by commit c8e88717cfc6b36bedea22368d97667446318291. Add it > > back. >

Re: [PATCH] KVM: VMX: re-add ple_gap module parameter

On Fri, 23 Nov 2018 19:42:53 +0200 Liran Alon wrote: > > On 23 Nov 2018, at 19:02, Luiz Capitulino wrote: > > > > > > Apparently, the ple_gap parameter was accidentally removed > > by commit c8e88717cfc6b36bedea22368d97667446318291. Add it > > back. >

[PATCH] KVM: VMX: re-add ple_gap module parameter

Apparently, the ple_gap parameter was accidentally removed by commit c8e88717cfc6b36bedea22368d97667446318291. Add it back. Signed-off-by: Luiz Capitulino --- arch/x86/kvm/vmx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 4555077d69ce

[PATCH] KVM: VMX: re-add ple_gap module parameter

Apparently, the ple_gap parameter was accidentally removed by commit c8e88717cfc6b36bedea22368d97667446318291. Add it back. Signed-off-by: Luiz Capitulino --- arch/x86/kvm/vmx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 4555077d69ce

Re: [PATCH v2 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization

ysical randomization. If the specified number of GB > huge pages is bigger than amount of good GB huge pages which system can > provide, it's consistent with the current huge page implementation. Reviewed-and-Tested-by: Luiz Capitulino > > v1->v2: > There are several code

Re: [PATCH v2 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization

ysical randomization. If the specified number of GB > huge pages is bigger than amount of good GB huge pages which system can > provide, it's consistent with the current huge page implementation. Reviewed-and-Tested-by: Luiz Capitulino > > v1->v2: > There are several code

Re: [PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization

On Mon, 28 May 2018 17:54:18 +0800 Baoquan He wrote: > On 05/23/18 at 03:10pm, Luiz Capitulino wrote: > > On Fri, 18 May 2018 19:28:36 +0800 > > Baoquan He wrote: > > > > > > Note that it's not KASLR specific: if we had some other kernel feature > &

Re: [PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization

On Mon, 28 May 2018 17:54:18 +0800 Baoquan He wrote: > On 05/23/18 at 03:10pm, Luiz Capitulino wrote: > > On Fri, 18 May 2018 19:28:36 +0800 > > Baoquan He wrote: > > > > > > Note that it's not KASLR specific: if we had some other kernel feature > &

Re: [GIT PULL] isolation: 1Hz residual tick offloading v4

> > > On Wed, Jan 24, 2018 at 10:46:08AM -0500, Luiz Capitulino wrote: > > > > [...] > > > > >> Since the 1Hz tick offload worked for you, I must be missing > > >> a way to disable this timer or the kernel is thinking my CPU > > &

Re: [GIT PULL] isolation: 1Hz residual tick offloading v4

On Fri, 25 May 2018 04:56:25 +0200 Frederic Weisbecker wrote: > On Tue, May 22, 2018 at 10:10:19PM +0300, Yauheni Kaliuta wrote: > > Hi, Frederic! > > > > >>>>> On Mon, 29 Jan 2018 02:10:26 +0100, Frederic Weisbecker wrote: > > > On Wed, Jan

Re: [PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization

On Fri, 18 May 2018 19:28:36 +0800 Baoquan He wrote: > > Note that it's not KASLR specific: if we had some other kernel feature that > > tried > > to allocate a piece of memory from what appears to be perfectly usable > > generic RAM > > we'd have the same problems! > >

Re: [PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization

On Fri, 18 May 2018 19:28:36 +0800 Baoquan He wrote: > > Note that it's not KASLR specific: if we had some other kernel feature that > > tried > > to allocate a piece of memory from what appears to be perfectly usable > > generic RAM > > we'd have the same problems! > > Hmm, this may not

Re: [GIT PULL] isolation: 1Hz residual tick offloading v4

On Mon, 29 Jan 2018 16:54:31 +0100 Peter Zijlstra <pet...@infradead.org> wrote: > On Mon, Jan 29, 2018 at 10:33:16AM -0500, Luiz Capitulino wrote: > > Cool, passing tsc=reliable worked for me. I finally got to the tick to > > go completely away. While I agree that fixing tha

Re: [GIT PULL] isolation: 1Hz residual tick offloading v4

On Mon, 29 Jan 2018 16:54:31 +0100 Peter Zijlstra wrote: > On Mon, Jan 29, 2018 at 10:33:16AM -0500, Luiz Capitulino wrote: > > Cool, passing tsc=reliable worked for me. I finally got to the tick to > > go completely away. While I agree that fixing that is beyond the scope > &

Re: [GIT PULL] isolation: 1Hz residual tick offloading v4

On Mon, 29 Jan 2018 02:10:26 +0100 Frederic Weisbecker <frede...@kernel.org> wrote: > On Wed, Jan 24, 2018 at 10:46:08AM -0500, Luiz Capitulino wrote: > > On Fri, 19 Jan 2018 01:02:14 +0100 > > Frederic Weisbecker <frede...@kernel.org> wrote: > > > > >

Re: [GIT PULL] isolation: 1Hz residual tick offloading v4

On Mon, 29 Jan 2018 02:10:26 +0100 Frederic Weisbecker wrote: > On Wed, Jan 24, 2018 at 10:46:08AM -0500, Luiz Capitulino wrote: > > On Fri, 19 Jan 2018 01:02:14 +0100 > > Frederic Weisbecker wrote: > > > > > Ingo, > > > > > > Pleas

Re: [GIT PULL] isolation: 1Hz residual tick offloading v4

On Fri, 19 Jan 2018 01:02:14 +0100 Frederic Weisbecker wrote: > Ingo, > > Please pull the sched/0hz-v2 branch that can be found at: > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > sched/0hz-v2 > > HEAD:

Re: [GIT PULL] isolation: 1Hz residual tick offloading v4

On Fri, 19 Jan 2018 01:02:14 +0100 Frederic Weisbecker wrote: > Ingo, > > Please pull the sched/0hz-v2 branch that can be found at: > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > sched/0hz-v2 > > HEAD: 9b14d5204490f9acd03998a5e406ecadb87cddba > >

Re: [GIT PULL] isolation: 1Hz residual tick offloading v3

On Thu, 18 Jan 2018 04:04:43 +0100 Frederic Weisbecker <frede...@kernel.org> wrote: > On Wed, Jan 17, 2018 at 12:38:01PM -0500, Luiz Capitulino wrote: > > On Tue, 16 Jan 2018 23:51:29 +0100 > > Frederic Weisbecker <frede...@kernel.org> wrote: > > > > >

Re: [GIT PULL] isolation: 1Hz residual tick offloading v3

On Thu, 18 Jan 2018 04:04:43 +0100 Frederic Weisbecker wrote: > On Wed, Jan 17, 2018 at 12:38:01PM -0500, Luiz Capitulino wrote: > > On Tue, 16 Jan 2018 23:51:29 +0100 > > Frederic Weisbecker wrote: > > > > > On Tue, Jan 16, 2018 at 11:52:11AM -0500, Luiz Capi

Re: [PATCH v7 0/5] x86/KASLR: Add parameter kaslr_mem=nn[KMG]@ss[KMG]

On Thu, 18 Jan 2018 09:11:14 +0800 Chao Fan <fanc.f...@cn.fujitsu.com> wrote: > On Wed, Jan 17, 2018 at 12:32:35PM -0500, Luiz Capitulino wrote: > >On Wed, 17 Jan 2018 18:53:46 +0800 > >Chao Fan <fanc.f...@cn.fujitsu.com> wrote: > > > >> ***Backg

Re: [PATCH v7 0/5] x86/KASLR: Add parameter kaslr_mem=nn[KMG]@ss[KMG]

On Thu, 18 Jan 2018 09:11:14 +0800 Chao Fan wrote: > On Wed, Jan 17, 2018 at 12:32:35PM -0500, Luiz Capitulino wrote: > >On Wed, 17 Jan 2018 18:53:46 +0800 > >Chao Fan wrote: > > > >> ***Background: > >> People reported that kaslr may randomly choose

Re: [GIT PULL] isolation: 1Hz residual tick offloading v3

On Tue, 16 Jan 2018 23:51:29 +0100 Frederic Weisbecker <frede...@kernel.org> wrote: > On Tue, Jan 16, 2018 at 11:52:11AM -0500, Luiz Capitulino wrote: > > On Tue, 16 Jan 2018 16:41:00 +0100 > > Frederic Weisbecker <frede...@kernel.org> wrote: > > > So isolcpu

Re: [GIT PULL] isolation: 1Hz residual tick offloading v3

On Tue, 16 Jan 2018 23:51:29 +0100 Frederic Weisbecker wrote: > On Tue, Jan 16, 2018 at 11:52:11AM -0500, Luiz Capitulino wrote: > > On Tue, 16 Jan 2018 16:41:00 +0100 > > Frederic Weisbecker wrote: > > > So isolcpus= is now the place where we control the isolation

Re: [PATCH v7 0/5] x86/KASLR: Add parameter kaslr_mem=nn[KMG]@ss[KMG]

On Wed, 17 Jan 2018 18:53:46 +0800 Chao Fan wrote: > ***Background: > People reported that kaslr may randomly chooses some positions > which are located in movable memory regions. This will break memory > hotplug feature. > > And also on kvm guest with 4GB meory, the

Re: [PATCH v7 0/5] x86/KASLR: Add parameter kaslr_mem=nn[KMG]@ss[KMG]

On Wed, 17 Jan 2018 18:53:46 +0800 Chao Fan wrote: > ***Background: > People reported that kaslr may randomly chooses some positions > which are located in movable memory regions. This will break memory > hotplug feature. > > And also on kvm guest with 4GB meory, the good unfragmented 1GB

Re: [PATCH 4/5] sched/isolation: Residual 1Hz scheduler tick offload

On Tue, 16 Jan 2018 16:57:45 +0100 Frederic Weisbecker <frede...@kernel.org> wrote: > On Fri, Jan 12, 2018 at 02:22:58PM -0500, Luiz Capitulino wrote: > > On Thu, 4 Jan 2018 05:25:36 +0100 > > Frederic Weisbecker <frede...@kernel.org> wrote: > > > >

Re: [PATCH 4/5] sched/isolation: Residual 1Hz scheduler tick offload

On Tue, 16 Jan 2018 16:57:45 +0100 Frederic Weisbecker wrote: > On Fri, Jan 12, 2018 at 02:22:58PM -0500, Luiz Capitulino wrote: > > On Thu, 4 Jan 2018 05:25:36 +0100 > > Frederic Weisbecker wrote: > > > > > When a CPU runs in full dynticks mode, a 1Hz tick

Re: [GIT PULL] isolation: 1Hz residual tick offloading v3

On Tue, 16 Jan 2018 16:41:00 +0100 Frederic Weisbecker <frede...@kernel.org> wrote: > On Fri, Jan 12, 2018 at 02:18:13PM -0500, Luiz Capitulino wrote: > > On Thu, 4 Jan 2018 05:25:32 +0100 > > Frederic Weisbecker <frede...@kernel.org> wrote: > > > > >

Re: [GIT PULL] isolation: 1Hz residual tick offloading v3

On Tue, 16 Jan 2018 16:41:00 +0100 Frederic Weisbecker wrote: > On Fri, Jan 12, 2018 at 02:18:13PM -0500, Luiz Capitulino wrote: > > On Thu, 4 Jan 2018 05:25:32 +0100 > > Frederic Weisbecker wrote: > > > > > Ingo, > > > > > > Pl

Re: [PATCH v6 5/5] kaslr: add kaslr_mem=nn[KMG]!ss[KMG] to avoid memory regions

On Tue, 16 Jan 2018 08:43:20 +0800 Baoquan He wrote: > On 01/15/18 at 08:49pm, Chao Fan wrote: > > Hi Luiz, > > > > I don't know if this patch is OK for you. > > Of coure you can only use kaslr_mem=nn@ss to solve the 1G huge page > > issue. Because we know the region [0,1G] is

Re: [PATCH v6 5/5] kaslr: add kaslr_mem=nn[KMG]!ss[KMG] to avoid memory regions

On Tue, 16 Jan 2018 08:43:20 +0800 Baoquan He wrote: > On 01/15/18 at 08:49pm, Chao Fan wrote: > > Hi Luiz, > > > > I don't know if this patch is OK for you. > > Of coure you can only use kaslr_mem=nn@ss to solve the 1G huge page > > issue. Because we know the region [0,1G] is not suitable for

Re: [PATCH 4/5] sched/isolation: Residual 1Hz scheduler tick offload

e global workqueues to the > housekeeping CPUs through /sys/devices/virtual/workqueue/cpumask or > domains isolation. > > Signed-off-by: Frederic Weisbecker <frede...@kernel.org> > Cc: Chris Metcalf <cmetc...@mellanox.com> > Cc: Christoph Lameter <c...@linux.com>

Re: [PATCH 4/5] sched/isolation: Residual 1Hz scheduler tick offload

> housekeeping CPUs through /sys/devices/virtual/workqueue/cpumask or > domains isolation. > > Signed-off-by: Frederic Weisbecker > Cc: Chris Metcalf > Cc: Christoph Lameter > Cc: Luiz Capitulino > Cc: Mike Galbraith > Cc: Paul E. McKenney > Cc: Peter Zijlstra &

Re: [GIT PULL] isolation: 1Hz residual tick offloading v3

On Thu, 4 Jan 2018 05:25:32 +0100 Frederic Weisbecker wrote: > Ingo, > > Please pull the sched/0hz branch that can be found at: > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > sched/0hz > > HEAD:

Re: [GIT PULL] isolation: 1Hz residual tick offloading v3

On Thu, 4 Jan 2018 05:25:32 +0100 Frederic Weisbecker wrote: > Ingo, > > Please pull the sched/0hz branch that can be found at: > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > sched/0hz > > HEAD: 9e932b2cc707209febd130978a5eb9f4a943a3f4 > > -- > Now

Re: KASLR may break some kernel features (was Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory)

>> > Hi Luiz, > >> > > >> > On 01/04/18 at 11:21am, Luiz Capitulino wrote: > >> >> Having a generic kaslr parameter to control where the kernel is > >> >> extracted > >> >> is one solution for this problem. > &

Re: KASLR may break some kernel features (was Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory)

On Fri, 12 Jan 2018 10:47:53 +0800 Chao Fan wrote: > On Fri, Jan 12, 2018 at 10:31:52AM +0800, Baoquan He wrote: > >On 01/11/18 at 10:04am, Kees Cook wrote: > >> On Thu, Jan 11, 2018 at 1:00 AM, Baoquan He wrote: > >> > Hi Luiz, > >> > > >&

Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory

On Fri, 5 Jan 2018 10:58:11 +0800 Chao Fan wrote: > On Thu, Jan 04, 2018 at 06:30:57PM +0800, Baoquan He wrote: > >On 01/04/18 at 04:02pm, Chao Fan wrote: > >> In current code, kaslr may choose the memory region in movable > >> nodes to extract kernel, which will make

Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory

On Fri, 5 Jan 2018 10:58:11 +0800 Chao Fan wrote: > On Thu, Jan 04, 2018 at 06:30:57PM +0800, Baoquan He wrote: > >On 01/04/18 at 04:02pm, Chao Fan wrote: > >> In current code, kaslr may choose the memory region in movable > >> nodes to extract kernel, which will make the nodes can't be

KASLR may break some kernel features (was Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory)

On Thu, 4 Jan 2018 18:30:57 +0800 Baoquan He wrote: > On 01/04/18 at 04:02pm, Chao Fan wrote: > > In current code, kaslr may choose the memory region in movable > > nodes to extract kernel, which will make the nodes can't be hot-removed. > > To solve it, we can specify the

KASLR may break some kernel features (was Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory)

On Thu, 4 Jan 2018 18:30:57 +0800 Baoquan He wrote: > On 01/04/18 at 04:02pm, Chao Fan wrote: > > In current code, kaslr may choose the memory region in movable > > nodes to extract kernel, which will make the nodes can't be hot-removed. > > To solve it, we can specify the memory region in

Re: [PATCH 4/5] sched/isolation: Residual 1Hz scheduler tick offload

On Tue, 19 Dec 2017 10:19:11 +0100 Peter Zijlstra wrote: > On Tue, Dec 19, 2017 at 04:23:57AM +0100, Frederic Weisbecker wrote: > > When a CPU runs in full dynticks mode, a 1Hz tick remains in order to > > keep the scheduler stats alive. However this residual tick is a

Re: [PATCH 4/5] sched/isolation: Residual 1Hz scheduler tick offload

On Tue, 19 Dec 2017 10:19:11 +0100 Peter Zijlstra wrote: > On Tue, Dec 19, 2017 at 04:23:57AM +0100, Frederic Weisbecker wrote: > > When a CPU runs in full dynticks mode, a 1Hz tick remains in order to > > keep the scheduler stats alive. However this residual tick is a burden > > for Real-Time

Re: [nohz_full/apic] multiple timer interrupts a second

On Sat, 04 Nov 2017 10:14:52 +0100 Nicolai Stange <nicsta...@gmail.com> wrote: > Hi Luiz, > > [John Stultz added to CC] > > On Fri, Nov 03 2017, Luiz Capitulino wrote: > > > [CC'ing lkml this time] > > > > I've observed that smp_apic_timer_interrupt()

Re: [nohz_full/apic] multiple timer interrupts a second

On Sat, 04 Nov 2017 10:14:52 +0100 Nicolai Stange wrote: > Hi Luiz, > > [John Stultz added to CC] > > On Fri, Nov 03 2017, Luiz Capitulino wrote: > > > [CC'ing lkml this time] > > > > I've observed that smp_apic_timer_interrupt() is sometimes c

[nohz_full/apic] multiple timer interrupts a second

[CC'ing lkml this time] Hi, I've observed that smp_apic_timer_interrupt() is sometimes called two or more times a second on a nohz_full core which has a single task taking 100% of the core. In one of the calls, hrtimer_interrupt() runs tick_sched_timer(), but in others it doesn't call any

[nohz_full/apic] multiple timer interrupts a second

[CC'ing lkml this time] Hi, I've observed that smp_apic_timer_interrupt() is sometimes called two or more times a second on a nohz_full core which has a single task taking 100% of the core. In one of the calls, hrtimer_interrupt() runs tick_sched_timer(), but in others it doesn't call any

Re: [RFC PATCH 7/9] housekeeping: Use own boot option, independant from nohz

On Mon, 14 Aug 2017 19:01:09 +0200 Frederic Weisbecker wrote: > > > Perhaps I should remove the nohz_full= parameter altogether and let > > > nohz_full controlled > > > by housekeeping= only. How much can kernel parameters be considered as > > > kernel ABIs? > > > >

Re: [RFC PATCH 7/9] housekeeping: Use own boot option, independant from nohz

On Mon, 14 Aug 2017 19:01:09 +0200 Frederic Weisbecker wrote: > > > Perhaps I should remove the nohz_full= parameter altogether and let > > > nohz_full controlled > > > by housekeeping= only. How much can kernel parameters be considered as > > > kernel ABIs? > > > > That's a very good

Re: [RFC PATCH 7/9] housekeeping: Use own boot option, independant from nohz

On Sat, 12 Aug 2017 16:10:06 +0200 Frederic Weisbecker <fweis...@gmail.com> wrote: > On Fri, Aug 11, 2017 at 03:09:57PM -0400, Luiz Capitulino wrote: > > On Fri, 21 Jul 2017 15:21:28 +0200 > > Frederic Weisbecker <fweis...@gmail.com> wrote: > > >

Re: [RFC PATCH 7/9] housekeeping: Use own boot option, independant from nohz

On Sat, 12 Aug 2017 16:10:06 +0200 Frederic Weisbecker wrote: > On Fri, Aug 11, 2017 at 03:09:57PM -0400, Luiz Capitulino wrote: > > On Fri, 21 Jul 2017 15:21:28 +0200 > > Frederic Weisbecker wrote: > > > -void __init housekeeping_init(void) > > > +/* Parse th

Re: [RFC PATCH 0/9] Introduce housekeeping subsystem

On Fri, 11 Aug 2017 17:01:30 +0200 Frederic Weisbecker wrote: > > Personally, I think NOHZ_FULL_ALL should just die. > > Yeah, although it's still useful for automatic boot testing to detect issues > with nohz_full on. Maybe we could rename/modify it to be a boot-time

Re: [RFC PATCH 0/9] Introduce housekeeping subsystem

On Fri, 11 Aug 2017 17:01:30 +0200 Frederic Weisbecker wrote: > > Personally, I think NOHZ_FULL_ALL should just die. > > Yeah, although it's still useful for automatic boot testing to detect issues > with nohz_full on. Maybe we could rename/modify it to be a boot-time testing option for

Re: [RFC PATCH 7/9] housekeeping: Use own boot option, independant from nohz

ith <efa...@gmx.de> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: Christoph Lameter <c...@linux.com> > Cc: Paul E. McKenney <paul...@linux.vnet.ibm.com> > Cc: Wanpeng Li <kernel...@gmail.com> > Cc: Luiz Capitulino <lcapitul...@redhat.com> > ---

Re: [RFC PATCH 7/9] housekeeping: Use own boot option, independant from nohz

-by: Frederic Weisbecker > Cc: Chris Metcalf > Cc: Rik van Riel > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: Mike Galbraith > Cc: Ingo Molnar > Cc: Christoph Lameter > Cc: Paul E. McKenney > Cc: Wanpeng Li > Cc: Luiz Capitulino > --- > inclu

Re: [RFC PATCH 0/5] vtime: Fix wrong user and system time accounting

series Frederic! This fixes all instances of the issue for me on bare-metal and KVM guests, even acct-bug[1] is fixed. Tested-by: Luiz Capitulino <lcapitul...@redhat.com> [1] http://people.redhat.com/~lcapitul/real-time/acct-bug.c

Re: [RFC PATCH 0/5] vtime: Fix wrong user and system time accounting

ll instances of the issue for me on bare-metal and KVM guests, even acct-bug[1] is fixed. Tested-by: Luiz Capitulino [1] http://people.redhat.com/~lcapitul/real-time/acct-bug.c

Re: [RFC PATCH 0/5] vtime: Fix wrong user and system time accounting

On Fri, 30 Jun 2017 09:41:18 +0800 Wanpeng Li wrote: > Hi Luiz, > > 2017-06-30 1:15 GMT+08:00 Frederic Weisbecker : > > Hi, > > > > This is a proposition to fix > > "[BUG nohz]: wrong user and system time accounting": > >

Re: [RFC PATCH 0/5] vtime: Fix wrong user and system time accounting

On Fri, 30 Jun 2017 09:41:18 +0800 Wanpeng Li wrote: > Hi Luiz, > > 2017-06-30 1:15 GMT+08:00 Frederic Weisbecker : > > Hi, > > > > This is a proposition to fix > > "[BUG nohz]: wrong user and system time accounting": > > http://lkml.kernel.org/r/20170323165512.60945...@redhat.com > > >

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Fri, 19 May 2017 12:13:26 -0500 (CDT) Christoph Lameter wrote: > > So why are you against integrating this simple, isolated patch which > > does not affect how current logic works? > > Frankly the argument does not make sense. Vmstat updates occur very > infrequently

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Fri, 19 May 2017 12:13:26 -0500 (CDT) Christoph Lameter wrote: > > So why are you against integrating this simple, isolated patch which > > does not affect how current logic works? > > Frankly the argument does not make sense. Vmstat updates occur very > infrequently (probably even less

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Tue, 2 May 2017 13:52:00 -0300 Marcelo Tosatti wrote: > > I have several questions about the tunables: > > > > - What does the vmstat_threshold value mean? What are the implications > >of changing this value? What's the difference in choosing 1, 2, 3 > >or 500?

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Tue, 2 May 2017 13:52:00 -0300 Marcelo Tosatti wrote: > > I have several questions about the tunables: > > > > - What does the vmstat_threshold value mean? What are the implications > >of changing this value? What's the difference in choosing 1, 2, 3 > >or 500? > > Its the

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Tue, 25 Apr 2017 10:57:19 -0300 Marcelo Tosatti wrote: > The per-CPU vmstat worker is a problem on -RT workloads (because > ideally the CPU is entirely reserved for the -RT app, without > interference). The worker transfers accumulated per-CPU > vmstat counters to global

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Tue, 25 Apr 2017 10:57:19 -0300 Marcelo Tosatti wrote: > The per-CPU vmstat worker is a problem on -RT workloads (because > ideally the CPU is entirely reserved for the -RT app, without > interference). The worker transfers accumulated per-CPU > vmstat counters to global counters. This is a

Re: [PATCH] tick/nohz: Fix wrong user and system time accouting against vtime sampling

enter_user() // cputime update > > The nohz_full CPU receives an interrupt at the same time the timer > interrupt fires on the housekeeping CPU. > > This patch offsets the tick to avert all ticks alignment in order > that the vtime sampling does not end up "in pha

Re: [PATCH] tick/nohz: Fix wrong user and system time accouting against vtime sampling

ate_jiffies > enter_user() // cputime update > > > exit_user() // no cputime update > tick X+1 update_jiffies > enter_user() // cputime update > > The nohz_

Re: [BUG nohz]: wrong user and system time accounting

On Mon, 3 Apr 2017 15:06:13 -0400 Luiz Capitulino <lcapitul...@redhat.com> wrote: > On Mon, 3 Apr 2017 17:23:17 +0200 > Frederic Weisbecker <fweis...@gmail.com> wrote: > > > Do you observe aligned ticks with trace events (hrtimer_expire_entry)? > > > > You

Re: [BUG nohz]: wrong user and system time accounting

On Mon, 3 Apr 2017 15:06:13 -0400 Luiz Capitulino wrote: > On Mon, 3 Apr 2017 17:23:17 +0200 > Frederic Weisbecker wrote: > > > Do you observe aligned ticks with trace events (hrtimer_expire_entry)? > > > > You might want to enforce the global clock to trace that

Re: [BUG nohz]: wrong user and system time accounting

On Mon, 3 Apr 2017 17:23:17 +0200 Frederic Weisbecker wrote: > Do you observe aligned ticks with trace events (hrtimer_expire_entry)? > > You might want to enforce the global clock to trace that: > > echo "global" > /sys/kernel/debug/tracing/trace_clock I've used the

Re: [BUG nohz]: wrong user and system time accounting

On Mon, 3 Apr 2017 17:23:17 +0200 Frederic Weisbecker wrote: > Do you observe aligned ticks with trace events (hrtimer_expire_entry)? > > You might want to enforce the global clock to trace that: > > echo "global" > /sys/kernel/debug/tracing/trace_clock I've used the same trace points &

Re: [BUG nohz]: wrong user and system time accounting

On Sat, 1 Apr 2017 01:24:54 +0200 Frederic Weisbecker <fweis...@gmail.com> wrote: > On Fri, Mar 31, 2017 at 04:09:10PM -0400, Luiz Capitulino wrote: > > On Thu, 30 Mar 2017 17:25:46 -0400 > > Luiz Capitulino <lcapitul...@redhat.com> wrote: > > > &g

Re: [BUG nohz]: wrong user and system time accounting

On Sat, 1 Apr 2017 01:24:54 +0200 Frederic Weisbecker wrote: > On Fri, Mar 31, 2017 at 04:09:10PM -0400, Luiz Capitulino wrote: > > On Thu, 30 Mar 2017 17:25:46 -0400 > > Luiz Capitulino wrote: > > > > > On Thu, 30 Mar 2017 16:18:17 +0200 &g

Re: [BUG nohz]: wrong user and system time accounting

On Thu, 30 Mar 2017 17:25:46 -0400 Luiz Capitulino <lcapitul...@redhat.com> wrote: > On Thu, 30 Mar 2017 16:18:17 +0200 > Frederic Weisbecker <fweis...@gmail.com> wrote: > > > On Thu, Mar 30, 2017 at 09:59:54PM +0800, Wanpeng Li wrote: > > > 2017-03-30

Re: [BUG nohz]: wrong user and system time accounting

On Thu, 30 Mar 2017 17:25:46 -0400 Luiz Capitulino wrote: > On Thu, 30 Mar 2017 16:18:17 +0200 > Frederic Weisbecker wrote: > > > On Thu, Mar 30, 2017 at 09:59:54PM +0800, Wanpeng Li wrote: > > > 2017-03-30 21:38 GMT+08:00 Frederic Weisbecker : > > > &

Re: [BUG nohz]: wrong user and system time accounting

On Thu, 30 Mar 2017 16:18:17 +0200 Frederic Weisbecker wrote: > On Thu, Mar 30, 2017 at 09:59:54PM +0800, Wanpeng Li wrote: > > 2017-03-30 21:38 GMT+08:00 Frederic Weisbecker : > > > If it works, we may want to take that solution, likely less performance

Re: [BUG nohz]: wrong user and system time accounting

On Thu, 30 Mar 2017 16:18:17 +0200 Frederic Weisbecker wrote: > On Thu, Mar 30, 2017 at 09:59:54PM +0800, Wanpeng Li wrote: > > 2017-03-30 21:38 GMT+08:00 Frederic Weisbecker : > > > If it works, we may want to take that solution, likely less performance > > > sensitive > > > than using

Re: [BUG nohz]: wrong user and system time accounting

On Thu, 30 Mar 2017 06:46:30 +0800 Wanpeng Li wrote: > > So! Now we need to find a proper fix :o) > > > > Hmm, how bad would it be to revert to sched_clock() instead of jiffies in > > vtime_delta()? > > We could use nanosecond granularity to check deltas but only perform an

Re: [BUG nohz]: wrong user and system time accounting

On Thu, 30 Mar 2017 06:46:30 +0800 Wanpeng Li wrote: > > So! Now we need to find a proper fix :o) > > > > Hmm, how bad would it be to revert to sched_clock() instead of jiffies in > > vtime_delta()? > > We could use nanosecond granularity to check deltas but only perform an > > actual cputime

Re: [BUG nohz]: wrong user and system time accounting

On Wed, 29 Mar 2017 23:12:00 +0200 Frederic Weisbecker <fweis...@gmail.com> wrote: > On Wed, Mar 29, 2017 at 09:23:57AM -0400, Luiz Capitulino wrote: > > > > There are various reproducers actually. I started off with the simple > > loop above, then wrote the attach pro

Re: [BUG nohz]: wrong user and system time accounting

On Wed, 29 Mar 2017 23:12:00 +0200 Frederic Weisbecker wrote: > On Wed, Mar 29, 2017 at 09:23:57AM -0400, Luiz Capitulino wrote: > > > > There are various reproducers actually. I started off with the simple > > loop above, then wrote the attach program and then wro

Re: [BUG nohz]: wrong user and system time accounting

On Wed, 29 Mar 2017 09:14:32 -0400 Rik van Riel wrote: > > I failed to reproduce with your config. I'm still getting 99% > > userspace > > cputime. So I'm wondering if the hogging style plays a role. > > > > I run pure user loops: > > > > int main(int argc, char **argv) >

Re: [BUG nohz]: wrong user and system time accounting

On Wed, 29 Mar 2017 09:14:32 -0400 Rik van Riel wrote: > > I failed to reproduce with your config. I'm still getting 99% > > userspace > > cputime. So I'm wondering if the hogging style plays a role. > > > > I run pure user loops: > > > > int main(int argc, char **argv) > > { > >   

Re: [BUG nohz]: wrong user and system time accounting

On Tue, 28 Mar 2017 17:24:11 -0400 Rik van Riel <r...@redhat.com> wrote: > On Tue, 2017-03-28 at 16:14 -0400, Luiz Capitulino wrote: > > > And I think I was right, it looks like the nohz code is programming > > the tick period incorrectly when restarting the tick. T

Re: [BUG nohz]: wrong user and system time accounting

On Tue, 28 Mar 2017 17:24:11 -0400 Rik van Riel wrote: > On Tue, 2017-03-28 at 16:14 -0400, Luiz Capitulino wrote: > > > And I think I was right, it looks like the nohz code is programming > > the tick period incorrectly when restarting the tick. The patch below > > fi

Re: [BUG nohz]: wrong user and system time accounting

On Tue, 28 Mar 2017 17:01:52 -0400 Rik van Riel <r...@redhat.com> wrote: > On Tue, 2017-03-28 at 16:14 -0400, Luiz Capitulino wrote: > > On Tue, 28 Mar 2017 13:24:06 -0400 > > Luiz Capitulino <lcapitul...@redhat.com> wrote: > > > I'm starting to suspect t

Re: [BUG nohz]: wrong user and system time accounting

On Tue, 28 Mar 2017 17:01:52 -0400 Rik van Riel wrote: > On Tue, 2017-03-28 at 16:14 -0400, Luiz Capitulino wrote: > > On Tue, 28 Mar 2017 13:24:06 -0400 > > Luiz Capitulino wrote: > > > I'm starting to suspect that the nohz code may be programming > > > the t

Re: [BUG nohz]: wrong user and system time accounting

On Tue, 28 Mar 2017 13:28:13 +0800 Wanpeng Li <kernel...@gmail.com> wrote: > 2017-03-28 2:38 GMT+08:00 Luiz Capitulino <lcapitul...@redhat.com>: > > On Mon, 27 Mar 2017 09:56:47 +0800 > > Wanpeng Li <kernel...@gmail.com> wrote: > > > >&g

Re: [BUG nohz]: wrong user and system time accounting

On Tue, 28 Mar 2017 13:28:13 +0800 Wanpeng Li wrote: > 2017-03-28 2:38 GMT+08:00 Luiz Capitulino : > > On Mon, 27 Mar 2017 09:56:47 +0800 > > Wanpeng Li wrote: > > > >> Actually after I bisect, the first bad commit is ff9a9b4c4334 ("sched, > >> t

Re: [BUG nohz]: wrong user and system time accounting

On Mon, 27 Mar 2017 09:56:47 +0800 Wanpeng Li wrote: > Actually after I bisect, the first bad commit is ff9a9b4c4334 ("sched, > time: Switch VIRT_CPU_ACCOUNTING_GEN to jiffy granularity"). The bug > can be reproduced readily if CONFIG_CONTEXT_TRACKING_FORCE is true, > then

Re: [BUG nohz]: wrong user and system time accounting

On Mon, 27 Mar 2017 09:56:47 +0800 Wanpeng Li wrote: > Actually after I bisect, the first bad commit is ff9a9b4c4334 ("sched, > time: Switch VIRT_CPU_ACCOUNTING_GEN to jiffy granularity"). The bug > can be reproduced readily if CONFIG_CONTEXT_TRACKING_FORCE is true, > then just stress all the

Re: [BUG nohz]: wrong user and system time accounting

On Fri, 24 Mar 2017 09:52:11 +0800 Wanpeng Li <kernel...@gmail.com> wrote: > 2017-03-24 4:55 GMT+08:00 Luiz Capitulino <lcapitul...@redhat.com>: > > > > When there are two or more tasks executing in user-space and > > taking 100% of a nohz_full CPU, top reports

Re: [BUG nohz]: wrong user and system time accounting

On Fri, 24 Mar 2017 09:52:11 +0800 Wanpeng Li wrote: > 2017-03-24 4:55 GMT+08:00 Luiz Capitulino : > > > > When there are two or more tasks executing in user-space and > > taking 100% of a nohz_full CPU, top reports 70% system time > > and 30% user time utilizati

  1   2   3   4   5   6   >