On Mon, Jun 24, 2019 at 04:53:53PM +0800, Wanpeng Li wrote:
> On Sat, 22 Jun 2019 at 06:11, Marcelo Tosatti wrote:
> >
> > On Fri, Jun 21, 2019 at 09:42:39AM +0800, Wanpeng Li wrote:
> > > On Thu, 20 Jun 2019 at 05:04, Marcelo Tosatti wrote:
> > > >
> >
On Fri, Jun 21, 2019 at 09:42:39AM +0800, Wanpeng Li wrote:
> On Thu, 20 Jun 2019 at 05:04, Marcelo Tosatti wrote:
> >
> > Hi Li,
> >
> > On Wed, Jun 19, 2019 at 08:36:06AM +0800, Wanpeng Li wrote:
> > > On Tue, 18 Jun 2019 at 21:36, Marcelo Tosatti wrote:
>
Hi Li,
On Wed, Jun 19, 2019 at 08:36:06AM +0800, Wanpeng Li wrote:
> On Tue, 18 Jun 2019 at 21:36, Marcelo Tosatti wrote:
> >
> > On Mon, Jun 17, 2019 at 07:24:44PM +0800, Wanpeng Li wrote:
> > > From: Wanpeng Li
> > >
> > > Dedicated instances are cur
> Avg time
>
> EXTERNAL_INTERRUPT6871 9.29% 2.96% 0.44us57.88us 0.72us (
> +- 4.02% )
>
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Cc: Marcelo Tosatti
> Signed-off-by: Wanpeng Li
> ---
> arch/x86/kvm/lapic.c| 33
On Wed, Jun 12, 2019 at 05:22:31PM +0200, Radim Krčmář wrote:
> 2019-06-12 09:48+0800, Wanpeng Li:
> > On Wed, 12 Jun 2019 at 04:39, Marcelo Tosatti wrote:
> > > On Tue, Jun 11, 2019 at 08:17:07PM +0800, Wanpeng Li wrote:
> > > > From: Wanpeng Li
> > > >
On Wed, Jun 12, 2019 at 08:45:10AM +0800, Wanpeng Li wrote:
> On Wed, 12 Jun 2019 at 04:39, Marcelo Tosatti wrote:
> >
> > On Tue, Jun 11, 2019 at 08:17:06PM +0800, Wanpeng Li wrote:
> > > From: Wanpeng Li
> > >
> > > Make lapic timer unpinned
On Tue, Jun 11, 2019 at 08:17:06PM +0800, Wanpeng Li wrote:
> From: Wanpeng Li
>
> Make lapic timer unpinned when timer is injected by posted-interrupt,
> the emulated timer can be offload to the housekeeping cpus.
>
> The host admin should fine tuned, e.g. dedicated instances scenario
> w/ noh
On Tue, Jun 11, 2019 at 08:17:07PM +0800, Wanpeng Li wrote:
> From: Wanpeng Li
>
> Dedicated instances are currently disturbed by unnecessary jitter due
> to the emulated lapic timers fire on the same pCPUs which vCPUs resident.
> There is no hardware virtual timer on Intel for guest like ARM. B
oes not suite for a new one".
Hi Peter,
I think its a dead parameter: you always want to use the local base
if the timer is not pinned.
> CC: Thomas Gleixner
> CC: John Stultz
> CC: Stephen Boyd
> CC: Luiz Capitulino
> CC: Marcelo Tosatti
> CC: linux-kernel@vger.kernel.o
On Tue, Jun 04, 2019 at 02:29:31PM +0800, Peter Xu wrote:
> On Mon, Apr 15, 2019 at 05:12:15PM -0300, Marcelo Tosatti wrote:
> > Check base->pending_map locklessly and skip raising timer softirq
> > if empty.
> >
> > What allows the lockless (and potentially racy ag
ode and then tried to understand the commit
> messages. It is easier, if it works the other way round.
Right. Commit message seemed descriptive to me, but i should probably
try to improve the explanation in the commit message.
> On Mon, 15 Apr 2019, Marcelo Tosatti wrote:
>
> > For isolat
Hi Anna-Maria,
On Wed, May 29, 2019 at 04:53:05PM +0200, Anna-Maria Gleixner wrote:
> On Mon, 15 Apr 2019, Marcelo Tosatti wrote:
>
> [...]
>
> > The patch "timers: do not raise softirq unconditionally" from Thomas
> > attempts to address that by checki
On Wed, May 29, 2019 at 04:53:26PM +0200, Anna-Maria Gleixner wrote:
> On Mon, 15 Apr 2019, Marcelo Tosatti wrote:
>
> > Check base->pending_map locklessly and skip raising timer softirq
> > if empty.
> >
> > What allows the lockless (and potentially racy agai
On Thu, May 16, 2019 at 09:32:06PM -0700, Ankur Arora wrote:
> On 2019-05-15 1:43 p.m., Marcelo Tosatti wrote:
> >On Wed, May 15, 2019 at 11:42:56AM -0700, Ankur Arora wrote:
> >>On 5/14/19 6:50 AM, Marcelo Tosatti wrote:
> >>>On Mon, May 13, 2019 at 05:20:37PM +08
On Wed, May 15, 2019 at 11:42:56AM -0700, Ankur Arora wrote:
> On 5/14/19 6:50 AM, Marcelo Tosatti wrote:
> >On Mon, May 13, 2019 at 05:20:37PM +0800, Wanpeng Li wrote:
> >>On Wed, 8 May 2019 at 02:57, Marcelo Tosatti wrote:
> >>>
> >>>
> >>&
On Wed, May 15, 2019 at 09:42:48AM +0800, Wanpeng Li wrote:
> On Wed, 15 May 2019 at 02:20, Marcelo Tosatti wrote:
> >
> > On Tue, May 14, 2019 at 11:20:15AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Tue, May 14, 2019 at 10:50:23AM -0300, Marcelo Tosatti wrote:
> &g
On Tue, May 14, 2019 at 11:20:15AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, May 14, 2019 at 10:50:23AM -0300, Marcelo Tosatti wrote:
> > On Mon, May 13, 2019 at 05:20:37PM +0800, Wanpeng Li wrote:
> > > On Wed, 8 May 2019 at 02:57, Marcelo Tosatti wrote:
> > >
On Mon, May 13, 2019 at 05:20:37PM +0800, Wanpeng Li wrote:
> On Wed, 8 May 2019 at 02:57, Marcelo Tosatti wrote:
> >
> >
> > Certain workloads perform poorly on KVM compared to baremetal
> > due to baremetal's ability to perform mwait on NEED_RESCHED
> > bit
On Wed, May 08, 2019 at 12:15:19AM +0200, Peter Zijlstra wrote:
> On Tue, May 07, 2019 at 03:56:49PM -0300, Marcelo Tosatti wrote:
> >
> > Certain workloads perform poorly on KVM compared to baremetal
> > due to baremetal's ability to perform mwait on NEED_RESCHED
> &
Host: 31.814230202231556
Guest: 38.1771876513 (83 %)
Guest, idle_spin=50us: 33.31770989804 (95 %)
Guest, idle_spin=220us: 32.2782655149 (98 %)
Signed-off-by: Marcelo Tosatti
---
kernel/sched/idle.c |
On Mon, Apr 15, 2019 at 05:12:13PM -0300, Marcelo Tosatti wrote:
> For isolated CPUs, we'd like to skip awakening ktimersoftd
> (the switch to and then back from ktimersoftd takes 10us in
> virtualized environments, in addition to other OS overhead,
> which exceeds telco requir
On Mon, Apr 15, 2019 at 05:12:13PM -0300, Marcelo Tosatti wrote:
> For isolated CPUs, we'd like to skip awakening ktimersoftd
> (the switch to and then back from ktimersoftd takes 10us in
> virtualized environments, in addition to other OS overhead,
> which exceeds telco requir
Condense the pending bitmap information in a bool.
Improves cyclictest results by 4us.
Signed-off-by: Marcelo Tosatti
---
kernel/time/timer.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
Index: linux-rt-devel/kernel/time/timer.c
etween timer addition and timer interrupt
execution by unconditionally (in case of isolated CPUs) raising the
timer softirq after making sure the updated bitmap is visible
on remote CPUs.
This patch reduces cyclictest latency from 25us to 14us
on my testbox.
Signed-off-by: Marcelo
Check base->pending_map locklessly and skip raising timer softirq
if empty.
What allows the lockless (and potentially racy against mod_timer)
check is that mod_timer will raise another timer softirq after
modifying base->pending_map.
Signed-off-by: Marcelo Tosatti
---
kernel/time/t
For isolated CPUs, we'd like to skip awakening ktimersoftd
(the switch to and then back from ktimersoftd takes 10us in
virtualized environments, in addition to other OS overhead,
which exceeds telco requirements for packet forwarding for
5G) from the sched tick.
The patch "timers: do not raise sof
On Sat, Oct 06, 2018 at 03:28:05PM -0700, Andy Lutomirski wrote:
> On Sat, Oct 6, 2018 at 1:29 PM Marcelo Tosatti wrote:
> >
> > On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote:
> > > For better or for worse, I'm trying to understand this code. So
On Fri, Sep 29, 2017 at 07:05:41PM +0200, Paolo Bonzini wrote:
> On 29/09/2017 18:40, Marcelo Tosatti wrote:
> >> If you know you have this kind disk workload, you must use virtio-blk or
> >> virtio-scsi with iothreads and place the iothreads on their own physical
> >&
On Fri, Sep 29, 2017 at 10:18:25AM +0200, Paolo Bonzini wrote:
> On 28/09/2017 23:35, Marcelo Tosatti wrote:
> > On Thu, Sep 28, 2017 at 09:22:02AM +0200, Paolo Bonzini wrote:
> >> On 28/09/2017 02:44, Marcelo Tosatti wrote:
> >>>> Again: if you have many interru
On Thu, Sep 28, 2017 at 06:35:08PM -0300, Marcelo Tosatti wrote:
> On Thu, Sep 28, 2017 at 09:22:02AM +0200, Paolo Bonzini wrote:
> > On 28/09/2017 02:44, Marcelo Tosatti wrote:
> > >> Again: if you have many interruptions, it's not a flaw in KVM or QEMU's
> >
On Thu, Sep 28, 2017 at 09:22:02AM +0200, Paolo Bonzini wrote:
> On 28/09/2017 02:44, Marcelo Tosatti wrote:
> >> Again: if you have many interruptions, it's not a flaw in KVM or QEMU's
> >> design, it's just that someone is doing something stupid. It could
On Fri, Sep 22, 2017 at 08:23:02AM +0200, Jan Kiszka wrote:
> On 2017-09-22 03:19, Marcelo Tosatti wrote:
> > On Thu, Sep 21, 2017 at 07:45:32PM +0200, Jan Kiszka wrote:
> >> On 2017-09-21 13:38, Marcelo Tosatti wrote:
> >>> When executing guest vcpu-0 with FIFO:1 p
On Wed, Sep 27, 2017 at 11:37:48AM +0200, Paolo Bonzini wrote:
> On 27/09/2017 00:49, Marcelo Tosatti wrote:
> > On Mon, Sep 25, 2017 at 05:12:42PM +0200, Paolo Bonzini wrote:
> >> On 25/09/2017 11:13, Peter Zijlstra wrote:
> >>> On Sun, Sep 24, 2017 at 11:57:53P
On Mon, Sep 25, 2017 at 05:12:42PM +0200, Paolo Bonzini wrote:
> On 25/09/2017 11:13, Peter Zijlstra wrote:
> > On Sun, Sep 24, 2017 at 11:57:53PM -0300, Marcelo Tosatti wrote:
> >> I think you are missing the following point:
> >>
> >> "vcpu0 can
On Mon, Sep 25, 2017 at 11:13:16AM +0200, Peter Zijlstra wrote:
> On Sun, Sep 24, 2017 at 11:57:53PM -0300, Marcelo Tosatti wrote:
> > I think you are missing the following point:
> >
> > "vcpu0 can be interrupted when its not in a spinlock protected section,
> >
On Sun, Sep 24, 2017 at 09:05:44AM -0400, Paolo Bonzini wrote:
>
>
> - Original Message -
> > From: "Peter Zijlstra"
> > To: "Paolo Bonzini"
> > Cc: "Marcelo Tosatti" , "Konrad Rzeszutek Wilk"
> > , mi...@re
On Fri, Sep 22, 2017 at 02:59:51PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 22, 2017 at 09:36:39AM -0300, Marcelo Tosatti wrote:
> > On Fri, Sep 22, 2017 at 02:31:07PM +0200, Peter Zijlstra wrote:
> > > On Fri, Sep 22, 2017 at 09:16:40AM -0300, Marcelo Tosatti wrote:
> >
On Fri, Sep 22, 2017 at 03:01:41PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 22, 2017 at 09:40:05AM -0300, Marcelo Tosatti wrote:
>
> > Are you arguing its invalid for the following application to execute on
> > housekeeping vcpu of a realtime system:
>
On Fri, Sep 22, 2017 at 02:31:07PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 22, 2017 at 09:16:40AM -0300, Marcelo Tosatti wrote:
> > On Fri, Sep 22, 2017 at 12:00:05PM +0200, Peter Zijlstra wrote:
> > > On Thu, Sep 21, 2017 at 10:10:41PM -0300, Marcelo Tosatti wrote:
> >
On Fri, Sep 22, 2017 at 12:56:09PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 22, 2017 at 12:00:04PM +0200, Peter Zijlstra wrote:
> > On Thu, Sep 21, 2017 at 10:10:41PM -0300, Marcelo Tosatti wrote:
> > > When executing guest vcpu-0 with FIFO:1 priority, which is necessary
> &
On Fri, Sep 22, 2017 at 02:31:07PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 22, 2017 at 09:16:40AM -0300, Marcelo Tosatti wrote:
> > On Fri, Sep 22, 2017 at 12:00:05PM +0200, Peter Zijlstra wrote:
> > > On Thu, Sep 21, 2017 at 10:10:41PM -0300, Marcelo Tosatti wrote:
> >
On Fri, Sep 22, 2017 at 09:23:47AM +0200, Paolo Bonzini wrote:
> On 22/09/2017 03:08, Marcelo Tosatti wrote:
> > On Thu, Sep 21, 2017 at 03:49:33PM +0200, Paolo Bonzini wrote:
> >> On 21/09/2017 15:32, Konrad Rzeszutek Wilk wrote:
> >>> So the guest can change the sc
On Fri, Sep 22, 2017 at 12:00:05PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 21, 2017 at 10:10:41PM -0300, Marcelo Tosatti wrote:
> > When executing guest vcpu-0 with FIFO:1 priority, which is necessary
> > to
> > deal with the following situation:
> >
&g
On Thu, Sep 21, 2017 at 07:45:32PM +0200, Jan Kiszka wrote:
> On 2017-09-21 13:38, Marcelo Tosatti wrote:
> > When executing guest vcpu-0 with FIFO:1 priority, which is necessary to
> > deal with the following situation:
> >
> > VCPU-0 (housekeeping VCPU)
On Thu, Sep 21, 2017 at 04:06:28PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 21, 2017 at 09:36:53AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Thu, Sep 21, 2017 at 08:38:38AM -0300, Marcelo Tosatti wrote:
> > > Add hypercalls to spinlock/unlock to set/unset FIFO priority
On Thu, Sep 21, 2017 at 03:49:33PM +0200, Paolo Bonzini wrote:
> On 21/09/2017 15:32, Konrad Rzeszutek Wilk wrote:
> > So the guest can change the scheduling decisions at the host level?
> > And the host HAS to follow it? There is no policy override for the
> > host to say - nah, not going to do it
isable ability to use the hypercall, on a per-vcpu
basis.
Signed-off-by: Marcelo Tosatti
---
arch/x86/include/asm/kvm_host.h |4
arch/x86/include/uapi/asm/kvm.h |5 +
arch/x86/kvm/x86.c | 29 +
include/uapi/linux/kvm.h
DPDK should not enter the kernel (and housekeeping vcpu
performance is far from a key factor).
Signed-off-by: Marcelo Tosatti
---
Documentation/virtual/kvm/hypercalls.txt | 22 +++
arch/x86/kvm/x86.c | 43 +++
include/uapi/linux
Add hypercalls to spinlock/unlock to set/unset FIFO priority
for the vcpu, protected by a static branch to avoid performance
increase in the normal kernels.
Enable option by "kvmfifohc" kernel command line parameter (disabled
by default).
Signed-off-by: Marcelo Tosatti
---
arch/
DPDK should not enter the kernel (and housekeeping vcpu
performance is far from a key factor).
Signed-off-by: Marcelo Tosatti
On Thu, Aug 03, 2017 at 02:35:19PM +0200, Paolo Bonzini wrote:
> On 03/08/2017 01:21, Marcelo Tosatti wrote:
> >> - if (ka->use_master_clock ||
> >> - (gtod->clock.vclock_mode == VCLOCK_TSC && vcpus_matched))
> >> + if (ka->use_master_clock ||
On Wed, Aug 02, 2017 at 05:38:09PM +0300, Denis Plotnikov wrote:
> It's needed to notify the KVM guest about critical changes in pvclock
> and make it to update its masterclock.
>
> This is a part of the work aiming to make kvmclock be a clocksource
> providing valid cycles value for KVM masterclo
Hi Denis,
I'm all for this as well, the original submission suggested something
similar, someone said "use a scheme similar to vsyscalls",
therefore the internal copy of the fields.
More comments below.
On Wed, Aug 02, 2017 at 05:38:07PM +0300, Denis Plotnikov wrote:
> Since, KVM has been swit
On Tue, May 30, 2017 at 01:17:41PM -0500, Christoph Lameter wrote:
> On Fri, 26 May 2017, Marcelo Tosatti wrote:
>
> > > interrupts and scheduler ticks. But what does this have to do with vmstat?
> > >
> > > Show me your dpdk code running and trace the tick on /
On Thu, Jun 29, 2017 at 09:03:42PM -0700, Linus Torvalds wrote:
> On Thu, Jun 29, 2017 at 12:15 PM, Marcelo Tosatti wrote:
> > On Thu, Jun 29, 2017 at 09:13:29AM -0700, Linus Torvalds wrote:
> >>
> >> swait uses special locking and has odd semantics that are not
On Thu, Jun 29, 2017 at 09:03:42PM -0700, Linus Torvalds wrote:
> On Thu, Jun 29, 2017 at 12:15 PM, Marcelo Tosatti wrote:
> > On Thu, Jun 29, 2017 at 09:13:29AM -0700, Linus Torvalds wrote:
> >>
> >> swait uses special locking and has odd semantics that are not
On Thu, Jun 29, 2017 at 09:13:29AM -0700, Linus Torvalds wrote:
> On Thu, Jun 29, 2017 at 6:46 AM, Thomas Gleixner wrote:
> > On Thu, 29 Jun 2017, Greg KH wrote:
> >> On Thu, Jun 29, 2017 at 03:05:26PM +0200, Thomas Gleixner wrote:
> >> >
> >> > And who defined that it should not be used in real c
On Tue, May 16, 2017 at 10:50:00PM +0200, Radim Krčmář wrote:
> kvm master clock usually has a different frequency than the kernel boot
> clock. This is not a problem until the master clock is updated;
> update uses the current kernel boot clock to compute new kvm clock,
> which erases any kvm clo
On Thu, May 25, 2017 at 10:24:46PM -0500, Christoph Lameter wrote:
> On Thu, 25 May 2017, Marcelo Tosatti wrote:
>
> > Argument? We're showing you the data that this is causing a latency
> > problem for us.
>
> Sorry I am not sure where the data shows a latency pr
On Fri, May 19, 2017 at 01:49:34PM -0400, Luiz Capitulino wrote:
> 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 n
On Mon, May 22, 2017 at 11:38:02AM -0500, Christoph Lameter wrote:
> On Sat, 20 May 2017, Marcelo Tosatti wrote:
>
> > > And you can configure the interval of vmstat updates freely Set
> > > the vmstat_interval to 60 seconds instead of 2 for a try? Is that rare
> &
On Fri, May 19, 2017 at 12:13:26PM -0500, Christoph Lameter wrote:
> On Fri, 19 May 2017, Marcelo Tosatti wrote:
>
> > Use-case: realtime application on an isolated core which for some reason
> > updates vmstatistics.
>
> Ok that is already only happening every 2 sec
Hi Christoph,
On Tue, May 16, 2017 at 08:37:11AM -0500, Christoph Lameter wrote:
> On Mon, 15 May 2017, Marcelo Tosatti wrote:
>
> > > NOHZ already does that. I wanted to know what your problem is that you
> > > see. The latency issue has already been solved as far as I
On Fri, May 12, 2017 at 11:57:15AM -0500, Christoph Lameter wrote:
> On Fri, 12 May 2017, Marcelo Tosatti wrote:
>
> > > What exactly is the issue you are seeing and want to address? I think we
> > > have similar aims and as far as I know the current situation is alrea
On Fri, May 12, 2017 at 11:07:48AM -0500, Christoph Lameter wrote:
> On Fri, 12 May 2017, Marcelo Tosatti wrote:
>
> > In our case, vmstat updates are very rare (CPU is dominated by DPDK).
>
> What is the OS doing on the cores that DPDK runs on? I mean we here can
> cle
On Fri, May 12, 2017 at 10:11:14AM -0500, Christoph Lameter wrote:
> On Fri, 12 May 2017, Marcelo Tosatti wrote:
>
> > > A bit confused by this one. The vmstat worker is already disabled if there
> > > are no updates. Also the patches by Chris Metcalf on data plane mode ad
On Thu, May 11, 2017 at 10:37:07AM -0500, Christoph Lameter wrote:
> On Tue, 2 May 2017, Luiz Capitulino wrote:
>
> > Ah, OK. Got this now. I'll give this patch a try. But I think we want
> > to hear from Christoph (who worked on reducing the vmstat interruptions
> > in the past).
>
> A bit confu
On Wed, May 10, 2017 at 11:34:26AM -0400, Rik van Riel wrote:
> On Wed, 2017-05-03 at 15:40 -0300, Marcelo Tosatti wrote:
> > Following the reasoning on the last patch in the series,
> > this patch allows configuration of the per-CPU vmstat worker:
> > it allows the user t
Following the reasoning on the last patch in the series,
this patch allows configuration of the per-CPU vmstat worker:
it allows the user to disable the per-CPU vmstat worker.
Signed-off-by: Marcelo Tosatti
--- linux/mm/vmstat.c.sothresh 2017-05-03 11:01:17.465914562 -0300
+++ linux/mm
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.
To resolve the problem, create two tunables:
* Userspace configurable per-CPU
Remove unused quiet_vmstat function.
Signed-off-by: Marcelo Tosatti
---
include/linux/vmstat.h |1 -
mm/vmstat.c| 25 -
2 files changed, 26 deletions(-)
Index: linux-2.6-git-disable-vmstat-worker/include/linux/vmstat.h
threshold: by default the VM code calculates the size of
the per-CPU vmstat arrays. This tunable allows userspace to
configure the vmstat threshold values.
The patch below contains documentation which describes the tunables
in more detail.
Signed-off-by: Marcelo Tosatti
---
Documentation/vm
On Tue, May 02, 2017 at 01:15:27PM -0400, Luiz Capitulino wrote:
> 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 implicat
On Tue, May 02, 2017 at 10:28:36AM -0400, Luiz Capitulino wrote:
> 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
> >
On Tue, Apr 25, 2017 at 03:29:06PM -0400, Rik van Riel wrote:
> On Tue, 2017-04-25 at 10:57 -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).
Remove unused quiet_vmstat function.
Signed-off-by: Marcelo Tosatti
---
include/linux/vmstat.h |1 -
mm/vmstat.c| 25 -
2 files changed, 26 deletions(-)
Index: linux-2.6-git-disable-vmstat-worker/include/linux/vmstat.h
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.
To resolve the problem, create two tunables:
* Userspace configurable per-CPU
the tunables
in more detail.
Signed-off-by: Marcelo Tosatti
---
Documentation/vm/vmstat_thresholds.txt | 38 +
mm/vmstat.c| 248 +++--
2 files changed, 272 insertions(+), 14 deletions(-)
Index: linux-2.6-git-disable-vmstat-worker/mm
On Fri, Mar 24, 2017 at 09:48:31AM +0100, Dmitry Vyukov wrote:
> On Thu, Mar 23, 2017 at 9:42 PM, Marcelo Tosatti wrote:
> > On Thu, Mar 23, 2017 at 06:24:19PM +0100, David Hildenbrand wrote:
> >> No caller currently checks the return value of
> >> kvm_io_bus_unregis
On Thu, Mar 23, 2017 at 06:24:19PM +0100, David Hildenbrand wrote:
> No caller currently checks the return value of
> kvm_io_bus_unregister_dev(). This is evil, as all callers silently go on
> freeing their device. A stale reference will remain in the io_bus,
> getting at least used again, when the
On Wed, Mar 01, 2017 at 03:21:32PM +0100, Paolo Bonzini wrote:
>
>
> On 28/02/2017 03:45, Marcelo Tosatti wrote:
> > On Fri, Feb 24, 2017 at 04:34:52PM +0100, Paolo Bonzini wrote:
> >>
> >>
> >> On 24/02/2017 14:04, Marcelo Tosatti wrote:
> >>&g
On Fri, Feb 24, 2017 at 04:34:52PM +0100, Paolo Bonzini wrote:
>
>
> On 24/02/2017 14:04, Marcelo Tosatti wrote:
> >>>>> Whats the current usecase, or forseeable future usecase, for
> >>>>> save/restore
> >>>>> across preemption
On Fri, Feb 24, 2017 at 01:17:07PM +0100, Paolo Bonzini wrote:
>
>
> On 24/02/2017 12:50, Marcelo Tosatti wrote:
> >>>
> >>> On all other cpufreq implementations, these boundaries still need to
> >>> be set. Then, a "governor" must be s
On Fri, Feb 24, 2017 at 10:18:59AM +0100, Paolo Bonzini wrote:
>
>
> On 24/02/2017 00:19, Marcelo Tosatti wrote:
> >>> i.e. our feature implies userspace tasks pinned to isolated vCPUs.
> > This is how cpufreq-userspace works:
> >
> > 2.2 Governor
> &g
On Thu, Feb 23, 2017 at 06:35:24PM +0100, Paolo Bonzini wrote:
>
>
> On 03/02/2017 20:09, Radim Krcmar wrote:
> > One reason why we have a kernel/userspace split is to allow sharing of
> > CPU time. Each application then its state that the kernel keeps track
> > of and saves/restores while time-
On Fri, Feb 03, 2017 at 06:03:37PM +0100, Radim Krcmar wrote:
> 2017-02-02 15:47-0200, Marcelo Tosatti:
> > For most VMs, modifying the host frequency is an undesired
> > operation. Introduce ioctl to enable the guest to
> > modify host CPU frequency.
> >
> >
&
On Fri, Feb 03, 2017 at 05:43:50PM +0100, Radim Krcmar wrote:
> 2017-02-02 15:47-0200, Marcelo Tosatti:
> > Implement KVM hypercalls for the guest
> > to issue frequency changes.
> >
> > Current situation with DPDK and frequency changes is as follows:
> > An algor
On Fri, Feb 03, 2017 at 06:40:34PM +0100, Radim Krcmar wrote:
> 2017-02-02 15:47-0200, Marcelo Tosatti:
> > Implement min/max/up/down frequency change
> > KVM hypercalls. To be used by DPDK implementation.
> >
> > Also allow such hypercalls from guest userspace.
>
On Thu, Feb 02, 2017 at 03:47:58PM -0200, Marcelo Tosatti wrote:
> Implement min/max/up/down frequency change
> KVM hypercalls. To be used by DPDK implementation.
>
> Also allow such hypercalls from guest userspace.
>
> Signed-off-by: Marcelo Tosatti
>
> ---
>
Implement min/max/up/down frequency change
KVM hypercalls. To be used by DPDK implementation.
Also allow such hypercalls from guest userspace.
Signed-off-by: Marcelo Tosatti
---
Documentation/virtual/kvm/hypercalls.txt | 45 +++
arch/x86/kvm/x86.c
driver (intel_pstate=disable host kernel
command line option), and set cpufreq userspace governor for
the isolated pCPU.
Signed-off-by: Marcelo Tosatti
---
drivers/cpufreq/cpufreq_userspace.c | 172
include/linux/cpufreq.h |7 +
2 files
For most VMs, modifying the host frequency is an undesired
operation. Introduce ioctl to enable the guest to
modify host CPU frequency.
Signed-off-by: Marcelo Tosatti
---
arch/x86/include/asm/kvm_host.h |2 ++
arch/x86/include/uapi/asm/kvm.h |5 +
arch/x86/kvm/x86.c
Implement KVM hypercalls for the guest
to issue frequency changes.
Current situation with DPDK and frequency changes is as follows:
An algorithm in the guest decides when to increase/decrease
frequency based on the queue length of the device.
On the host, a power manager daemon is used to listen
On Wed, Jan 25, 2017 at 01:59:34PM +0100, Paolo Bonzini wrote:
>
>
> On 25/01/2017 13:55, Marcelo Tosatti wrote:
> > On Wed, Jan 25, 2017 at 01:30:49PM +0100, Paolo Bonzini wrote:
> >>
> >>
> >> On 24/01/2017 18:09, Marcelo Tosatti wrote:
> >>&g
On Wed, Jan 25, 2017 at 01:56:45PM +0100, Paolo Bonzini wrote:
>
>
> On 24/01/2017 18:09, Marcelo Tosatti wrote:
> > Add a driver with gettime method returning hosts realtime clock.
> > This allows Chrony to synchronize host and guest clocks with
> > high p
On Wed, Jan 25, 2017 at 01:30:49PM +0100, Paolo Bonzini wrote:
>
>
> On 24/01/2017 18:09, Marcelo Tosatti wrote:
> > Add a hypercall to retrieve the host realtime clock
> > and the TSC value used to calculate that clock read.
> >
> > Used to implement clock syn
To be used by KVM PTP driver.
Signed-off-by: Marcelo Tosatti
---
arch/x86/include/asm/kvmclock.h |6 ++
arch/x86/kernel/kvmclock.c |3 ++-
2 files changed, 8 insertions(+), 1 deletion(-)
v2: export kvmclock clocksource structure directly (Paolo)
Index: kvm-ptpdriver/arch/x86
This patchset implements a virtual PTP driver which allows guest to sync
its clock to the host clock with high precision
(error is < 1us on an idle guest).
Changelog from v4
Drop PTP_SYS_OFFSET emulation via ->crosstimestamp callback (Richard).
Emulate ->gettime directly without TSC offset (Radi
Expose the realtime host clock and save the TSC value
used for the clock calculation.
Signed-off-by: Marcelo Tosatti
---
arch/x86/kvm/x86.c | 36
1 file changed, 36 insertions(+)
v2: unify nsec_base (Radim)
Index: kvm-ptpdriver/arch/x86/kvm/x86.c
ock.
Signed-off-by: Marcelo Tosatti
---
drivers/ptp/Kconfig | 12 ++
drivers/ptp/Makefile |1
drivers/ptp/ptp_kvm.c | 202 ++
3 files changed, 215 insertions(+)
v2: check for kvmclock (Radim)
initialize global variables before dev
101 - 200 of 1338 matches
Mail list logo
