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
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 expens
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
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
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
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.
>
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
es when do kernel physical 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:
> T
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
>
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
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 b
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
> &
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,
> > >
> > > Please p
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
>
> Changes
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
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 chooses s
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 fe
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 could
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
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,
> > >
> > > Pleas
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 1
es to the
> 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 Z
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 that
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,
> >> >
> >&
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 hot-rem
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 immova
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 ta
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 someti
[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 handle
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 questi
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
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
nohz_
Signed-off-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
> ---
&
nstances 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
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
> >
>
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 tha
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 maximum
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
update_jiffies
> enter_user() // cputime update
>
>
> exit_user() // no cputime update
> tick X+1 update_jiffies
> enter_user() // cputime update
>
>
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
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 & de
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
> > > Frederic
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 :
> > > &
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 sched_
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 u
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
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)
> > {
> >
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
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
> > >
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
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 onl
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 utilization.
On Thu, 23 Mar 2017 21:08:38 -0400
Rik van Riel wrote:
> On Thu, 2017-03-23 at 21:05 -0400, Luiz Capitulino wrote:
> > On Thu, 23 Mar 2017 20:56:02 -0400
> > Rik van Riel wrote:
> >
> > > On Thu, 2017-03-23 at 16:55 -0400, Luiz Capitulino wrote:
> >
On Thu, 23 Mar 2017 20:56:02 -0400
Rik van Riel wrote:
> On Thu, 2017-03-23 at 16:55 -0400, Luiz Capitulino wrote:
> > 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 utili
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 utilization. Sometimes I'm even able to get
100% system time and 0% user time.
This was reproduced with latest Linus tree (093b995), but I
don't believe it's
The ftrace hwlat does support a cpumask.
Signed-off-by: Luiz Capitulino
---
kernel/trace/trace_hwlat.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/kernel/trace/trace_hwlat.c b/kernel/trace/trace_hwlat.c
index af344a1b..1199fe1 100644
--- a/kernel/trace/trace_hwlat.c
On Tue, 3 Jan 2017 11:45:30 -0500
Steven Rostedt wrote:
> On Tue, 3 Jan 2017 11:32:58 -0500
> Luiz Capitulino wrote:
>
> > On Tue, 22 Nov 2016 15:20:50 -0500
> > Luiz Capitulino wrote:
> >
> > > This series adds support for a --cpu-list option, which is
On Tue, 22 Nov 2016 15:20:50 -0500
Luiz Capitulino wrote:
> This series adds support for a --cpu-list option, which is
> much more human friendly than -M:
>
> # trace-cmd record --cpu-list 1,4,10-15 [...]
>
> The first patch is a small refectoring needed to
> make -
instead of cpu.h, which
makes the cpumask dynamic and avoid various bugs
- Small cleanups and renamings
Luiz Capitulino (2):
trace-cmd record: refactor set_mask()
trace-cmd record: add --cpu-list option
Documentation/trace-cmd-record.1.txt | 4 +
trace-local.h
his work is a preparation for supporting the
"--cpu-list" option in the next commit.
Signed-off-by: Luiz Capitulino
---
trace-local.h | 2 +-
trace-record.c | 54 ++
2 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/trace-
.
Signed-off-by: Luiz Capitulino
---
Documentation/trace-cmd-record.1.txt | 4 +
trace-record.c | 208 +++
2 files changed, 212 insertions(+)
diff --git a/Documentation/trace-cmd-record.1.txt
b/Documentation/trace-cmd-record.1.txt
index
On Tue, 15 Nov 2016 16:38:19 -0500
Steven Rostedt wrote:
> On Fri, 28 Oct 2016 17:14:56 -0400
> Luiz Capitulino wrote:
>
>
> > >
> > > cpu_set(ret_mask, i) sets bits from begin to end in uint64_t cpumask
> > > from below.
> > >
> > >
On Mon, 7 Nov 2016 17:55:47 +0100 (CET)
Thomas Gleixner wrote:
> On Sat, 5 Nov 2016, Chris Metcalf wrote:
> > == Remote statistics ==
> >
> > We discussed the possibility of remote statistics gathering, i.e. load
> > average etc. The idea would be that we could have housekeeping
> > core(s) per
On Fri, 28 Oct 2016 15:50:10 -0400
Steven Rostedt wrote:
> On Fri, 28 Oct 2016 15:49:22 -0400
> Steven Rostedt wrote:
>
> > Sorry it took so long to look at this, but I finally got around to
> > it ;-)
> >
>
> I did apply patches 1 and 2. I'm hoping to get them out tomorrow, or
> while I'm
On Fri, 28 Oct 2016 15:49:22 -0400
Steven Rostedt wrote:
> Sorry it took so long to look at this, but I finally got around to
> it ;-)
>
>
> On Fri, 7 Oct 2016 12:47:11 -0400
> Luiz Capitulino wrote:
>
> > With --cpu-list you can do:
> >
> >
On Fri, 7 Oct 2016 12:47:08 -0400
Luiz Capitulino wrote:
> This series adds support for a --cpu-list option, which is
> much more human friendly than -M:
>
> # trace-cmd record --cpu-list 1,4,10-15 [...]
>
> The first two patches are refactorings needed to make
> -
On Wed, 19 Oct 2016 09:55:23 -0400
Steven Rostedt wrote:
> On Wed, 19 Oct 2016 09:30:23 -0400
> Luiz Capitulino wrote:
>
> > On Fri, 7 Oct 2016 12:47:08 -0400
> > Luiz Capitulino wrote:
> >
> > > This series adds support for a --cpu-list option, whi
Today, we only ignore section 1. But we also have a
section 5 man page.
Signed-off-by: Luiz Capitulino
---
Documentation/.gitignore | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/.gitignore b/Documentation/.gitignore
index f7e585b..aecd243 100644
--- a
This commit does the following:
1. Move the code that treats "-M -1" out of set_mask()
2. Drop uneeded checks from set_mask()
3. Make instance->cpumask point to dynamic memory
This is a preparation for supporting the "--cpu-list"
option in the next commit.
Signed-
always be unsigned int.
Signed-off-by: Luiz Capitulino
---
cpu.h | 47 +--
1 file changed, 25 insertions(+), 22 deletions(-)
diff --git a/cpu.h b/cpu.h
index 05c7f17..fc0b3c4 100644
--- a/cpu.h
+++ b/cpu.h
@@ -20,45 +20,48 @@
#ifndef _CPU_H
#define _CPU_H
With --cpu-list you can do:
# trace-cmd record --cpu-list 1,4,10-15 [...]
Which is much more human friendly than -M.
Signed-off-by: Luiz Capitulino
---
Documentation/trace-cmd-record.1.txt | 4 +
trace-record.c | 138 +++
2 files
This series adds support for a --cpu-list option, which is
much more human friendly than -M:
# trace-cmd record --cpu-list 1,4,10-15 [...]
The first two patches are refactorings needed to make
--cpu-list support fit nicely. The third patch adds the
new option.
Luiz Capitulino (3):
cpu.h
On Fri, 16 Sep 2016 16:59:55 +0200
Paolo Bonzini wrote:
> On 16/09/2016 16:59, Luiz Capitulino wrote:
> > On Fri, 16 Sep 2016 16:56:34 +0200
> > Paolo Bonzini wrote:
> >
> >> On 16/09/2016 16:27, Luiz Capitulino wrote:
> >>> [Intro
On Fri, 16 Sep 2016 16:56:34 +0200
Paolo Bonzini wrote:
> On 16/09/2016 16:27, Luiz Capitulino wrote:
> > [Introduction will follow]
> >
> > Changelog
> > -
> >
> > v2
> >
> > - add tsc_offset field to struct kvm_vcpu_arch
> >
The TSC offset can now be read directly from struct kvm_arch_vcpu.
Signed-off-by: Luiz Capitulino
---
arch/x86/include/asm/kvm_host.h | 1 -
arch/x86/kvm/svm.c | 8
arch/x86/kvm/vmx.c | 6 --
arch/x86/kvm/x86.c | 2 +-
4 files changed, 1
ecific
per-vcpu information to user-space.
Signed-off-by: Luiz Capitulino
---
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c | 32
2 files changed, 33 insertions(+)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 5486ff9..01c0b9c 10
following files in debugfs:
/sys/kernel/debug/kvm/66828-10/vcpu0/tsc-offset
/sys/kernel/debug/kvm/66828-10/vcpu0/tsc-scaling-ratio
/sys/kernel/debug/kvm/66828-10/vcpu0/tsc-scaling-ratio-frac-bits
The last two are only created if TSC scaling is supported.
Signed-off-by: Luiz Capitulino
---
arch
x86, this commit introduces a new file to avoid growing
arch/x86/kvm/x86.c even more.
Signed-off-by: Luiz Capitulino
---
arch/arm/kvm/arm.c | 10 ++
arch/mips/kvm/mips.c | 10 ++
arch/powerpc/kvm/powerpc.c | 10 ++
arch/s390/kvm/kvm-s390.c | 10
devel] [RFC] host and guest kernel trace merging
https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg00887.html
Luiz Capitulino (6):
kvm: x86: add tsc_offset field to struct kvm_vcpu_arch
kvm: x86: drop read_tsc_offset()
kvm: kvm_destroy_vm_debugfs(): check debugfs_stat_data pointer
A future commit will want to easily read a vCPU's TSC offset,
so we store it in struct kvm_arch_vcpu_arch for easy access.
Signed-off-by: Luiz Capitulino
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/x86.c | 10 --
2 files changed, 9 insertions(+), 2 dele
Otherwise, the kernel panics when kvm_create_vm_debugfs()
fails before assigning this pointer.
Signed-off-by: Luiz Capitulino
---
virt/kvm/kvm_main.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 1950782..c1dc45e
On Fri, 2 Sep 2016 20:49:37 -0300
Marcelo Tosatti wrote:
> On Fri, Sep 02, 2016 at 09:43:01AM -0400, Stefan Hajnoczi wrote:
> > On Wed, Aug 31, 2016 at 01:05:45PM -0400, Luiz Capitulino wrote:
> > > We need to retrieve a VM's TSC offset in order to use
> > >
On Fri, 2 Sep 2016 19:00:41 +0200
Paolo Bonzini wrote:
> On 31/08/2016 19:05, Luiz Capitulino wrote:
> > vcpu0: 18446742405270834952
> > vcpu1: 18446742405270834952
> > vcpu2: 18446742405270834952
> > vcpu3: 18446742405270834952
> >
> >
On Fri, 2 Sep 2016 12:26:55 -0400
Luiz Capitulino wrote:
> I guess that what tools like trace-cmd want to do in those cases
> is to warn the user and discard the trace. A simple way of doing
> this would be to re-check that the TSC offset are the same after
> tracing is done. It co
On Fri, 2 Sep 2016 09:43:01 -0400
Stefan Hajnoczi wrote:
> On Wed, Aug 31, 2016 at 01:05:45PM -0400, Luiz Capitulino wrote:
> > We need to retrieve a VM's TSC offset in order to use
> > the host's TSC to merge host and guest traces. This is
> > exp
kvm_arch_create_vm_debugfs() allows arch specific code to
create entries in the VM's directory in debugfs. x86 will
implement support for this in the next commit.
Signed-off-by: Luiz Capitulino
---
arch/arm/kvm/arm.c | 5 +
arch/mips/kvm/mips.c | 5 +
arch/powerp
This make it possible to call kvm_destroy_vm_debugfs() from
kvm_create_vm_debugfs() in error conditions.
Signed-off-by: Luiz Capitulino
---
virt/kvm/kvm_main.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 1950782
er line, for each
vCPU. For example:
vcpu0: 18446742405270834952
vcpu1: 18446742405270834952
vcpu2: 18446742405270834952
vcpu3: 18446742405270834952
Please, see patch 4/4 for additional details.
Luiz Capitulino (4):
kvm: kvm_destroy_vm_debugfs(): check debugs_stat_data pointer
kvm:
sing only the TSC offset for now.
So, let's get this merged first and do the TSC multiplier
as a second step
Signed-off-by: Luiz Capitulino
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/svm.c | 1 +
arch/x86/kvm/vmx.c | 8
arch/x86/kvm/x8
Memory and debugfs entries are leaked on error. Fix it.
Signed-off-by: Luiz Capitulino
---
virt/kvm/kvm_main.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index c1dc45e..9293285 100644
--- a/virt/kvm/kvm_main.c
+++ b
On Thu, 4 Aug 2016 10:55:58 -0400
Luiz Capitulino wrote:
> The first patch fixes a real reproducible issue. The second one is
> more theoretical. Please, check the paches for more details.
Ping?
Just making sure this is not lost. Latest Linus tree doesn't
boot on my machines without patch 1/2.
cpuhp_setup_state() can fail. If it does, we have to
return 0 to upper layers.
Signed-off-by: Luiz Capitulino
---
arch/x86/kernel/apic/x2apic_cluster.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/apic/x2apic_cluster.c
b/arch/x86/kernel/apic
Commit 6b2c28471, moved the allocation of cpus_in_cluster
to the x2apic_prepare_cpu() callback. However, it forgot
to move the cpumask_set_cpu() call that uses it.
This generates a NULL pointer dereference during boot
in machines with x2apic_mode=true.
Signed-off-by: Luiz Capitulino
---
arch
The first patch fixes a real reproducible issue. The second one is
more theoretical. Please, check the paches for more details.
Luiz Capitulino (2):
x86/x2apic: fix NULL pointer def during boot
x86/x2apic: check return value on probe
arch/x86/kernel/apic/x2apic_cluster.c | 9 +
1
On Thu, 12 May 2016 16:08:34 +0200
Daniel Wagner wrote:
> In short, I haven't figured out yet why the kernel builds get slightly
> slower.
You're doing make -j 200, right? How many cores do you have? Couldn't it
be that you're saturating your CPUs?
You could try make -j, or some process creat
On Thu, 28 Apr 2016 14:57:24 +0200
Daniel Wagner wrote:
> From: Daniel Wagner
>
> Completions have no long lasting callbacks and therefore do not need
> the complex waitqueue variant. Use simple waitqueues which reduces
> the contention on the waitqueue lock.
>
> This was a carry forward from
nk I'd refactor the code opening tracing_on to its own
function so that we avoid the duplicate code in setup_tracer(),
but in any case:
Reviewed-by: Luiz Capitulino
On Tue, 3 May 2016 12:59:53 -0500
Clark Williams wrote:
> John,
>
> This patch is against the devel/v0.98 branch. It turns off tracing in the
> tracemark() so that we don't lose information about what was going on when we
> hit the latency:
>
>
> The current logic of using --tracemark and --
On Fri, 22 Apr 2016 07:12:51 +0800
Wanpeng Li wrote:
> 2016-04-05 20:40 GMT+08:00 Luiz Capitulino :
> > On Tue, 5 Apr 2016 14:18:01 +0800
> > Yang Zhang wrote:
> >
> >> On 2016/4/5 5:00, Rik van Riel wrote:
> >> > On Mon, 2016-04-04 at 16:46 -040
On Tue, 19 Apr 2016 15:17:33 +0200 (CEST)
John Kacur wrote:
> On Thu, 14 Apr 2016, Luiz Capitulino wrote:
>
> > On Wed, 13 Apr 2016 15:37:00 -0500
> > Clark Williams wrote:
> >
> > > John,
> > >
> > > I ran into issues wit
1 - 100 of 296 matches
Mail list logo
