On Thu, Apr 02, 2015 at 11:32:49AM +0800, Hillf Danton wrote:
> > --- a/kernel/time/tick-sched.c
> > +++ b/kernel/time/tick-sched.c
> > @@ -568,6 +568,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct
> > tick_sched *ts,
> > unsigned long rcu_delta_jiffies;
> > struct clock_event_device
On Thu, Apr 02, 2015 at 09:58:26AM -0400, Rik van Riel wrote:
> On 04/01/2015 09:44 PM, Marcelo Tosatti wrote:
>
> > +++ b/kernel/time/tick-sched.c
> > @@ -568,6 +568,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct
> > tick_sched *ts,
> > unsigned long rcu
On Thu, Apr 02, 2015 at 04:59:40PM +0200, Frederic Weisbecker wrote:
> On Wed, Apr 01, 2015 at 10:44:55PM -0300, Marcelo Tosatti wrote:
> >
> > It is only necessary to raise timer softirq
> > in case there are active timers or irq work
> > to do.
> >
> &
) ||
> + smp_rmb();
> + } while (unlikely((pvti->pvti.version & 1) ||
> pvti->pvti.version != version ||
> pvti->migrate_count != migrate_count));
>
> --
> 2.3.4
>
> --
> To unsubscribe f
: Luiz Capitulino
Signed-off-by: Marcelo Tosatti
diff --git a/include/linux/timer.h b/include/linux/timer.h
index 8c5a197..0c065f9 100644
--- a/include/linux/timer.h
+++ b/include/linux/timer.h
@@ -192,7 +192,7 @@ extern void set_timer_slack(struct timer_list *time, int
slack_hz);
* locks the
On Tue, Apr 07, 2015 at 01:34:15AM +0200, Frederic Weisbecker wrote:
> On Thu, Apr 02, 2015 at 06:08:09PM -0300, Marcelo Tosatti wrote:
> > On Thu, Apr 02, 2015 at 04:59:40PM +0200, Frederic Weisbecker wrote:
> > > On Wed, Apr 01, 2015 at 10:44:55PM -0300, Mar
On Mon, Apr 20, 2015 at 06:59:04PM +0200, Paolo Bonzini wrote:
>
>
> On 17/04/2015 22:18, Marcelo Tosatti wrote:
> > The bug which this is fixing is very rare, have no memory of a report.
> >
> > In fact, its even difficult to create a synthetic reproducer.
>
On Mon, Apr 20, 2015 at 01:27:58PM -0700, Andy Lutomirski wrote:
> On Mon, Apr 20, 2015 at 9:59 AM, Paolo Bonzini wrote:
> >
> >
> > On 17/04/2015 22:18, Marcelo Tosatti wrote:
> >> The bug which this is fixing is very rare, have no memory of a report.
> >&
On Wed, Apr 22, 2015 at 11:01:49PM +0200, Paolo Bonzini wrote:
>
>
> On 22/04/2015 22:56, Marcelo Tosatti wrote:
> >> > But then why was the task migration notifier even in Jeremy's original
> >> > code for Xen?
> > To cover for the vcpu1 -> vcpu2
On Thu, Apr 23, 2015 at 11:13:23AM +0200, Paolo Bonzini wrote:
>
>
> On 22/04/2015 23:21, Marcelo Tosatti wrote:
> > On Mon, Apr 20, 2015 at 01:27:58PM -0700, Andy Lutomirski wrote:
> >> On Mon, Apr 20, 2015 at 9:59 AM, Paolo Bonzini wrote:
> >>>
> >>
On Thu, Apr 23, 2015 at 02:02:29PM +0200, Paolo Bonzini wrote:
>
>
> On 23/04/2015 13:51, Marcelo Tosatti wrote:
> >>> > > https://bugzilla.redhat.com/show_bug.cgi?id=1174664
> >> >
> >> > That was the missing volatile in an asm. Older compi
On Mon, Mar 30, 2015 at 04:46:55AM +, Wu, Feng wrote:
>
>
> > -Original Message-
> > From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> > Sent: Saturday, March 28, 2015 3:30 AM
> > To: Wu, Feng
> > Cc: h...@zytor.com; t...@linutronix.de; mi..
On Thu, Mar 26, 2015 at 10:29:27PM -0300, Marcelo Tosatti wrote:
> On Thu, Mar 26, 2015 at 11:38:59AM -0700, Vikas Shivappa wrote:
> >
> > Hello Marcelo,
>
> Hi Vikas,
>
> > On Wed, 25 Mar 2015, Marcelo Tosatti wrote:
> >
> > >On Thu, Mar 12, 2
On Tue, Mar 31, 2015 at 10:27:26AM -0400, Rik van Riel wrote:
> CPUs with nohz_full do not want disruption from timer interrupts,
> or other random system things. This includes block mq work.
>
> There is another issue with block mq vs. realtime tasks that run
> 100% of the time, which is not unc
On Tue, Mar 31, 2015 at 10:27:32AM -0700, Vikas Shivappa wrote:
>
>
> On Thu, 26 Mar 2015, Marcelo Tosatti wrote:
>
> >
> >I can't find any discussion relating to exposing the CBM interface
> >directly to userspace in that thread ?
> >
> >Cpu.shar
On Tue, Mar 31, 2015 at 05:02:38PM +0200, Frederic Weisbecker wrote:
> On Tue, Mar 31, 2015 at 10:27:26AM -0400, Rik van Riel wrote:
> > CPUs with nohz_full do not want disruption from timer interrupts,
> > or other random system things. This includes block mq work.
> >
> > There is another issue
5,6 +1711,13 @@ static int kvm_guest_time_update(struct kvm_vcpu *v)
> kvm_write_guest_cached(v->kvm, &vcpu->pv_time,
> &vcpu->hv_clock,
> sizeof(vcpu->hv_clock));
> +
> + smp_wmb();
> +
> +
On Tue, Apr 07, 2015 at 10:17:23PM +0200, Frederic Weisbecker wrote:
> On Mon, Apr 06, 2015 at 08:51:26PM -0300, Marcelo Tosatti wrote:
> > On Tue, Apr 07, 2015 at 01:34:15AM +0200, Frederic Weisbecker wrote:
> > > Yeah, it would be nice to make sure that the cause of th
On Fri, Apr 17, 2015 at 03:38:58PM +0200, Paolo Bonzini wrote:
> On 17/04/2015 15:10, Peter Zijlstra wrote:
> > On Fri, Apr 17, 2015 at 02:46:57PM +0200, Paolo Bonzini wrote:
> >> On 17/04/2015 12:55, Peter Zijlstra wrote:
> >>> Also, it looks like you already do exactly this for other things, look
On Fri, Apr 17, 2015 at 09:57:12PM +0200, Paolo Bonzini wrote:
>
>
> >> From 4eb9d7132e1990c0586f28af3103675416d38974 Mon Sep 17 00:00:00 2001
> >> From: Paolo Bonzini
> >> Date: Fri, 17 Apr 2015 14:57:34 +0200
> >> Subject: [PATCH] sched: add CONFIG_TASK_MIGRATION_NOTIFIER
> >>
> >> The task mi
On Fri, Apr 17, 2015 at 03:25:28PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 17, 2015 at 3:04 PM, Linus Torvalds
> wrote:
> > On Fri, Apr 17, 2015 at 5:42 PM, Andy Lutomirski
> > wrote:
> >>
> >> Muahaha. The auditors have invaded your system. (I did my little
> >> benchmark with a more sens
On Thu, Mar 12, 2015 at 04:16:03PM -0700, Vikas Shivappa wrote:
> Add support for cache bit mask manipulation. The change adds a file to
> the RDT cgroup which represents the CBM(cache bit mask) for the cgroup.
>
> The RDT cgroup follows cgroup hierarchy ,mkdir and adding tasks to the
> cgroup nev
On Wed, Jul 18, 2012 at 06:58:24PM +0300, Michael S. Tsirkin wrote:
> > > > > > Back to original point though current
> > > > > > situation is that calling kvm_set_irq() under spinlock is not worse
> > > > > > for
> > > > > > scalability than calling it not under one.
> > > > >
> > > > > Yes. Sti
On Mon, Jul 02, 2012 at 05:52:39PM +0900, Takuya Yoshikawa wrote:
> v3->v4: Resolved trace_kvm_age_page() issue -- patch 6,7
> v2->v3: Fixed intersection calculations. -- patch 3, 8
>
> Takuya
>
> Takuya Yoshikawa (8):
> KVM: MMU: Use __gfn_to_rmap() to clean up kvm_handle_hva()
> KVM:
On Wed, Jul 18, 2012 at 11:48:50AM +0300, Avi Kivity wrote:
> Signed-off-by: Avi Kivity
> ---
> arch/x86/kernel/cpu/hypervisor.c | 2 ++
> 1 file changed, 2 insertions(+)
Applied to next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Wed, Jul 18, 2012 at 02:28:34PM -0600, Alex Williamson wrote:
> > turn on lockdep to remember why I couldn't sleep there.
>
> switching to a mutex results in:
>
> BUG: sleeping function called from invalid context at kernel/mutex.c:269
> in_atomic(): 1, irqs_disabled(): 0, pid: 30025, name: qe
On Tue, Jul 17, 2012 at 09:52:13PM +0800, Xiao Guangrong wrote:
> Introduce set_mmio_exit_info to cleanup the common code
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/kvm/x86.c | 33 +
> 1 files changed, 17 insertions(+), 16 deletions(-)
This makes the co
On Tue, Jul 17, 2012 at 09:53:29PM +0800, Xiao Guangrong wrote:
> If it have no indirect shadow pages we need not protect any gfn,
> this is always true for direct mmu without nested
>
> Signed-off-by: Xiao Guangrong
Xiao,
What is the motivation? Numbers please.
In fact, what case was the orig
Applied all patches except 2, 3 and 5, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tue, Jul 17, 2012 at 09:51:34PM +0800, Xiao Guangrong wrote:
> No need split mmio read region into 8-bits pieces since we do it in
> emulator_read_write_onepage
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/kvm/emulate.c | 29 -
> 1 files changed, 12 inserti
On Tue, Jul 17, 2012 at 09:52:52PM +0800, Xiao Guangrong wrote:
> It will trigger a WARN_ON if the page has been freed but it is still
> used in mmu, it can help us to detect mm bug early
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/kvm/mmu.c |8
> 1 files changed, 8 insertion
On Fri, Jul 20, 2012 at 11:45:59AM +0800, Xiao Guangrong wrote:
> BTW, they are some bug fix patches on -master branch, but
> it is not existed on -next branch:
> commit: f411930442e01f9cf1bf4df41ff7e89476575c4d
> commit: 85b7059169e128c57a3a8a3e588fb89cb2031da1
>
> It causes code conflict if we d
On Fri, Jul 20, 2012 at 10:17:36AM +0800, Xiao Guangrong wrote:
> On 07/20/2012 07:58 AM, Marcelo Tosatti wrote:
>
> >> - }
> >> + rc = ctxt->ops->read_emulated(ctxt, addr, mc->data + mc->end, size,
> >> +&ctx
On Fri, Jul 20, 2012 at 10:34:28AM +0800, Xiao Guangrong wrote:
> On 07/20/2012 08:39 AM, Marcelo Tosatti wrote:
> > On Tue, Jul 17, 2012 at 09:53:29PM +0800, Xiao Guangrong wrote:
> >> If it have no indirect shadow pages we need not protect any gfn,
> >> this is always
Linus,
Please pull from
git://git.kernel.org/pub/scm/virt/kvm/kvm.git master
To receive the following KVM bug fix, which restores
APIC migration functionality.
Radim Krčmář (1):
KVM: x86: fix lapic.timer_mode on restore
arch/x86/kvm/lapic.c | 26 --
1 file c
On Tue, Apr 14, 2015 at 07:37:44AM +, Wu, Feng wrote:
>
>
> > -Original Message-
> > From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> > Sent: Tuesday, March 31, 2015 7:56 AM
> > To: Wu, Feng
> > Cc: h...@zytor.com; t...@linutronix.de; mi..
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
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
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
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 Fri, Feb 12, 2021 at 01:25:21PM +0100, Frederic Weisbecker wrote:
> On Thu, Jan 28, 2021 at 05:21:36PM -0300, Marcelo Tosatti wrote:
> > Rather than waking up all nohz_full CPUs on the system, only wakeup
> > the target CPUs of member threads of the signal.
> >
> &g
On Thu, Jan 28, 2021 at 05:02:41PM +0100, Thomas Gleixner wrote:
> On Wed, Jan 27 2021 at 09:19, Marcelo Tosatti wrote:
> > On Wed, Jan 27, 2021 at 11:57:16AM +, Robin Murphy wrote:
> >> > +hk_flags = HK_FLAG_DOMAIN | HK_FLAG_MANAGED_IRQ;
> >> > +
On Thu, Jan 28, 2021 at 04:56:07PM +0100, Thomas Gleixner wrote:
> On Wed, Jan 27 2021 at 10:09, Marcelo Tosatti wrote:
> > On Wed, Jan 27, 2021 at 12:36:30PM +, Robin Murphy wrote:
> >> > > >/**
> >> > > > * cpumask_next - get the next c
If the task is not running, run_posix_cpu_timers has nothing
to elapsed, so spare IPI in that case.
Suggested-by: Peter Zijlstra
Signed-off-by: Marcelo Tosatti
Index: linux-2.6/kernel/sched/core.c
===
--- linux-2.6.orig/kernel
and task->tick_dep_mask.
From: Frederic Weisbecker
Suggested-by: Peter Zijlstra
Signed-off-by: Frederic Weisbecker
Signed-off-by: Marcelo Tosatti
Index: linux-2.6/kernel/time/tick-sched.c
===
--- linux-2.6.orig/kernel/tim
Rather than waking up all nohz_full CPUs on the system, only wakeup
the target CPUs of member threads of the signal.
Reduces interruptions to nohz_full CPUs.
Signed-off-by: Marcelo Tosatti
Index: linux-2.6/kernel/time/tick-sched.c
When enabling per-CPU posix timers, an IPI to nohz_full CPUs might be
performed (to re-read the dependencies and possibly not re-enter
nohz_full on a given CPU).
A common case is for applications that run on nohz_full= CPUs
to not use POSIX timers (eg DPDK). This patch changes the notification
to
When enabling per-CPU posix timers, an IPI to nohz_full CPUs might be
performed (to re-read the dependencies and possibly not re-enter
nohz_full on a given CPU).
A common case is for applications that run on nohz_full= CPUs
to not use POSIX timers (eg DPDK). This patch changes the notification
to
and task->tick_dep_mask.
From: Frederic Weisbecker
Suggested-by: Peter Zijlstra
Signed-off-by: Frederic Weisbecker
Signed-off-by: Marcelo Tosatti
Index: linux-2.6/kernel/time/tick-sched.c
===
--- linux-2.6.orig/kernel/tim
Rather than waking up all nohz_full CPUs on the system, only wakeup
the target CPUs of member threads of the signal.
Reduces interruptions to nohz_full CPUs.
Signed-off-by: Marcelo Tosatti
Index: linux-2.6/kernel/time/tick-sched.c
If the task is not running, run_posix_cpu_timers has nothing
to elapsed, so spare IPI in that case.
Suggested-by: Peter Zijlstra
Signed-off-by: Marcelo Tosatti
Index: linux-2.6/kernel/sched/core.c
===
--- linux-2.6.orig/kernel
On Fri, Jan 29, 2021 at 07:41:27AM -0800, Alex Belits wrote:
> On 1/28/21 07:56, Thomas Gleixner wrote:
> > External Email
> >
> > --
> > On Wed, Jan 27 2021 at 10:09, Marcelo Tosatti wrote:
> >
On Thu, Jan 28, 2021 at 09:01:37PM +0100, Thomas Gleixner wrote:
> On Thu, Jan 28 2021 at 13:59, Marcelo Tosatti wrote:
> >> The whole pile wants to be reverted. It's simply broken in several ways.
> >
> > I was asking for your comments on interaction with CPU hotplug
On Thu, Feb 04, 2021 at 01:47:38PM -0500, Nitesh Narayan Lal wrote:
>
> On 2/4/21 1:15 PM, Marcelo Tosatti wrote:
> > On Thu, Jan 28, 2021 at 09:01:37PM +0100, Thomas Gleixner wrote:
> >> On Thu, Jan 28 2021 at 13:59, Marcelo Tosatti wrote:
> >>>> The whole pi
On Wed, Dec 09, 2020 at 09:58:23PM +0100, Thomas Gleixner wrote:
> Marcelo,
>
> On Wed, Dec 09 2020 at 13:34, Marcelo Tosatti wrote:
> > On Tue, Dec 08, 2020 at 10:33:15PM +0100, Thomas Gleixner wrote:
> >> On Tue, Dec 08 2020 at 15:11, Marcelo Tosatti wrote:
> >&
On Thu, Dec 10, 2020 at 10:48:10PM +0100, Thomas Gleixner wrote:
> On Thu, Dec 10 2020 at 12:26, Marcelo Tosatti wrote:
> > On Wed, Dec 09, 2020 at 09:58:23PM +0100, Thomas Gleixner wrote:
> >> Marcelo,
> >>
> >> On Wed, Dec 09 2020 at 13:34, Marcelo Tosatti w
On Fri, Dec 11, 2020 at 02:30:34PM +0100, Thomas Gleixner wrote:
> On Thu, Dec 10 2020 at 21:27, Marcelo Tosatti wrote:
> > On Thu, Dec 10, 2020 at 10:48:10PM +0100, Thomas Gleixner wrote:
> >> You really all live in a seperate universe creating your own rules how
> >>
On Sun, Dec 06, 2020 at 05:19:16PM +0100, Thomas Gleixner wrote:
> On Thu, Dec 03 2020 at 19:11, Maxim Levitsky wrote:
> > + case KVM_SET_TSC_STATE: {
> > + struct kvm_tsc_state __user *user_tsc_state = argp;
> > + struct kvm_tsc_state tsc_state;
> > + u64 host_tsc,
On Thu, Dec 03, 2020 at 07:11:16PM +0200, Maxim Levitsky wrote:
> These two new ioctls allow to more precisly capture and
> restore guest's TSC state.
>
> Both ioctls are meant to be used to accurately migrate guest TSC
> even when there is a significant downtime during the migration.
>
> Suggest
On Thu, Dec 03, 2020 at 07:11:15PM +0200, Maxim Levitsky wrote:
> Hi!
>
> This is the second version of the work to make TSC migration more accurate,
> as was defined by Paulo at:
> https://www.spinics.net/lists/kvm/msg225525.html
Maxim,
Can you please make a description of what is the practical
On Mon, Dec 07, 2020 at 10:04:45AM -0800, Andy Lutomirski wrote:
>
> > On Dec 7, 2020, at 9:00 AM, Maxim Levitsky wrote:
> >
> > On Mon, 2020-12-07 at 08:53 -0800, Andy Lutomirski wrote:
> On Dec 7, 2020, at 8:38 AM, Thomas Gleixner wrote:
> >>>
> >>> On Mon, Dec 07 2020 at 14:16, Maxim
On Tue, Dec 08, 2020 at 04:50:53PM +0200, Maxim Levitsky wrote:
> On Mon, 2020-12-07 at 20:29 -0300, Marcelo Tosatti wrote:
> > On Thu, Dec 03, 2020 at 07:11:16PM +0200, Maxim Levitsky wrote:
> > > These two new ioctls allow to more precisly capture and
> > >
On Tue, Dec 08, 2020 at 05:02:07PM +0100, Thomas Gleixner wrote:
> On Tue, Dec 08 2020 at 16:50, Maxim Levitsky wrote:
> > On Mon, 2020-12-07 at 20:29 -0300, Marcelo Tosatti wrote:
> >> > +This ioctl allows to reconstruct the guest's IA32_TSC and TSC_ADJUST
> >
On Tue, Dec 08, 2020 at 06:25:13PM +0200, Maxim Levitsky wrote:
> On Tue, 2020-12-08 at 17:02 +0100, Thomas Gleixner wrote:
> > On Tue, Dec 08 2020 at 16:50, Maxim Levitsky wrote:
> > > On Mon, 2020-12-07 at 20:29 -0300, Marcelo Tosatti wrote:
> > > > > +Thi
has active timers in the CLOCK_REALTIME and CLOCK_TAI bases. If
that's not the case, update the realtime and TAI base offsets remotely and
skip the IPI. This ensures that any subsequently armed timers on
CLOCK_REALTIME and CLOCK_TAI are evaluated with the correct offsets.
Signed-off-by: Ma
active timers in the CLOCK_REALTIME and CLOCK_TAI bases. If
that's not the case, update the realtime and TAI base offsets remotely and
skip the IPI. This ensures that any subsequently armed timers on
CLOCK_REALTIME and CLOCK_TAI are evaluated with the correct offsets.
Signed-off-by: Marcelo To
has active timers in the CLOCK_REALTIME and CLOCK_TAI bases. If
that's not the case, update the realtime and TAI base offsets remotely and
skip the IPI. This ensures that any subsequently armed timers on
CLOCK_REALTIME and CLOCK_TAI are evaluated with the correct offsets.
Signed-off-by: Ma
offsets remotely, skipping the IPI.
This reduces interruptions to latency sensitive applications.
Signed-off-by: Marcelo Tosatti
---
v2:
- Only REALTIME and TAI bases are affected by offset-to-monotonic changes
(Thomas).
- Don't special case nohz_full CPUs (Thomas).
diff --git a/k
On Sat, Apr 17, 2021 at 06:51:08PM +0200, Thomas Gleixner wrote:
> On Sat, Apr 17 2021 at 18:24, Thomas Gleixner wrote:
> > On Fri, Apr 16 2021 at 13:13, Peter Xu wrote:
> >> On Fri, Apr 16, 2021 at 01:00:23PM -0300, Marcelo Tosatti wrote:
> >>>
>
has active timers in the CLOCK_REALTIME and CLOCK_TAI bases. If
that's not the case, update the realtime and TAI base offsets remotely and
skip the IPI. This ensures that any subsequently armed timers on
CLOCK_REALTIME and CLOCK_TAI are evaluated with the correct offsets.
Signed-off-by: Ma
+CC Anna-Maria.
On Fri, Apr 09, 2021 at 04:15:13PM +0200, Thomas Gleixner wrote:
> On Wed, Apr 07 2021 at 10:53, Marcelo Tosatti wrote:
> > Setting the realtime clock triggers an IPI to all CPUs to reprogram
> > hrtimers.
> >
> > However, only base, boottime and ta
On Tue, Dec 08, 2020 at 10:33:15PM +0100, Thomas Gleixner wrote:
> On Tue, Dec 08 2020 at 15:11, Marcelo Tosatti wrote:
> > On Tue, Dec 08, 2020 at 05:02:07PM +0100, Thomas Gleixner wrote:
> >> On Tue, Dec 08 2020 at 16:50, Maxim Levitsky wrote:
> >> > On Mon, 2020
Hi Maxim,
On Mon, Nov 30, 2020 at 03:35:57PM +0200, Maxim Levitsky wrote:
> Hi!
>
> This is the first version of the work to make TSC migration more accurate,
> as was defined by Paulo at:
> https://www.spinics.net/lists/kvm/msg225525.html
Description from Oliver's patch:
"To date, VMMs have ty
On Thu, Dec 03, 2020 at 01:39:42PM +0200, Maxim Levitsky wrote:
> On Tue, 2020-12-01 at 16:48 -0300, Marcelo Tosatti wrote:
> > On Tue, Dec 01, 2020 at 02:30:39PM +0200, Maxim Levitsky wrote:
> > > On Mon, 2020-11-30 at 16:16 -0300, Marcelo Tosatti wrote:
> > > >
On Tue, Dec 01, 2020 at 02:48:11PM +0100, Thomas Gleixner wrote:
> On Mon, Nov 30 2020 at 16:16, Marcelo Tosatti wrote:
> >> Besides, Linux guests don't sync the TSC via IA32_TSC write,
> >> but rather use IA32_TSC_ADJUST which currently doesn't participate
On Tue, Dec 01, 2020 at 02:30:39PM +0200, Maxim Levitsky wrote:
> On Mon, 2020-11-30 at 16:16 -0300, Marcelo Tosatti wrote:
> > Hi Maxim,
> >
> > On Mon, Nov 30, 2020 at 03:35:57PM +0200, Maxim Levitsky wrote:
> > > Hi!
> > >
> > > This is the firs
On Thu, Oct 01, 2020 at 04:47:31PM +0200, Frederic Weisbecker wrote:
> On Wed, Jul 22, 2020 at 02:58:24PM +, Alex Belits wrote:
> > From: Yuri Norov
> >
> > so we don't need to flush it.
>
> What guarantees that we have no backlog on it?
>From Paolo's work to use lockless reading of
per-C
On Tue, Nov 24, 2020 at 12:21:06AM +0100, Frederic Weisbecker wrote:
> On Mon, Nov 23, 2020 at 10:39:34PM +, Alex Belits wrote:
> >
> > On Mon, 2020-11-23 at 23:29 +0100, Frederic Weisbecker wrote:
> > > External Email
> > >
> > > --
On Wed, Jan 27, 2021 at 11:57:16AM +, Robin Murphy wrote:
> Hi,
>
> On 2020-06-25 23:34, Nitesh Narayan Lal wrote:
> > From: Alex Belits
> >
> > The current implementation of cpumask_local_spread() does not respect the
> > isolated CPUs, i.e., even if a CPU has been isolated for Real-Time ta
On Wed, Jan 27, 2021 at 12:36:30PM +, Robin Murphy wrote:
> On 2021-01-27 12:19, Marcelo Tosatti wrote:
> > On Wed, Jan 27, 2021 at 11:57:16AM +, Robin Murphy wrote:
> > > Hi,
> > >
> > > On 2020-06-25 23:34, Nitesh Narayan Lal wrote:
> > &
On Fri, Dec 11, 2020 at 10:59:59PM +0100, Paolo Bonzini wrote:
> On 11/12/20 22:04, Thomas Gleixner wrote:
> > > Its 100ms off with migration, and can be reduced further (customers
> > > complained about 5 seconds but seem happy with 0.1ms).
> > What is 100ms? Guaranteed maximum migration time?
>
On Thu, Nov 26, 2020 at 07:24:41PM +0100, Rafael J. Wysocki wrote:
> On Thu, Nov 26, 2020 at 6:25 PM Mel Gorman
> wrote:
> >
> > It was noted that a few workloads that idle rapidly regressed when commit
> > 36fcb4292473 ("cpuidle: use first valid target residency as poll time")
> > was merged. Th
On Mon, Feb 24, 2014 at 04:42:29PM +0100, Andrew Jones wrote:
> When the tsc is marked unstable on the host it causes global clock
> updates to be requested each time a vcpu is loaded, nearly halting
> all progress on guests with a large number of vcpus.
>
> Fix this by only requesting a local clo
On Wed, Feb 26, 2014 at 07:15:12PM +0100, Andrew Jones wrote:
> commit 0061d53daf26f introduced a mechanism to execute a global clock
> update for a vm. We can apply this periodically in order to propagate
> host NTP corrections. Also, if all vcpus of a vm are pinned, then
> without an additional t
On Wed, Feb 26, 2014 at 07:15:11PM +0100, Andrew Jones wrote:
> When we update a vcpu's local clock it may pick up an NTP correction.
> We can't wait an indeterminate amount of time for other vcpus to pick
> up that correction, so commit 0061d53daf26f introduced a global clock
> update. However, we
On Fri, Nov 01, 2013 at 10:08:55AM -0600, Greg Edwards wrote:
> When determining the page size we could use to map with the IOMMU, the
> page size should be aligned with the hva, not the gfn. The gfn may not
> reflect the real alignment within the hugetlbfs file.
>
> Most of the time, this works
p */
> + while (__gfn_to_hva_memslot(slot, gfn) & (page_size - 1))
> + page_size >>= 1;
> +
> /*
>* Pin all pages we are about to map in memory. This is
> * important because we unmap and un
On Tue, Mar 11, 2014 at 07:11:18PM +0100, Radim Krčmář wrote:
> We always disable cr8 intercept in its handler, but only re-enable it
> if handling KVM_REQ_EVENT, so there can be a window where we do not
> intercept cr8 writes, which allows an interrupt to disrupt a higher
> priority task.
>
> Fix
On Wed, Mar 12, 2014 at 11:40:48AM +0100, Radim Krčmář wrote:
> 2014-03-11 22:05-0300, Marcelo Tosatti:
> > On Tue, Mar 11, 2014 at 07:11:18PM +0100, Radim Krčmář wrote:
> > > We always disable cr8 intercept in its handler, but only re-enable it
> > > if handling KVM_R
On Fri, Feb 28, 2014 at 12:52:53PM +0100, Andrew Jones wrote:
> This patch series addresses two issues with global clock updates.
> The first fixes a bug found on hosts that have a tsc marked as
> unstable. As global clock updates get triggered on every vcpu load
> in these cases, guests with a lar
On Tue, Feb 11, 2014 at 09:25:14AM +, Mel Gorman wrote:
> On Mon, Feb 10, 2014 at 06:54:20PM -0800, David Rientjes wrote:
> > On Mon, 10 Feb 2014, Luiz Capitulino wrote:
> >
> > > HugeTLB command-line option hugepages= allows the user to specify how many
> > > huge pages should be allocated at
On Tue, Feb 11, 2014 at 05:10:35PM +, Mel Gorman wrote:
> On Tue, Feb 11, 2014 at 01:26:29PM -0200, Marcelo Tosatti wrote:
> > > Or take a stab at allocating 1G pages at runtime. It would require
> > > finding properly aligned 1Gs worth of contiguous MAX_ORDER_NR_PAGE
On Tue, Feb 18, 2014 at 02:16:42PM -0800, David Rientjes wrote:
> On Tue, 18 Feb 2014, Marcelo Tosatti wrote:
>
> > > Lacking from your entire patchset is a specific example of what you want
> > > to do. So I think we're all guessing what exactly your usecase is and
On Wed, Feb 19, 2014 at 07:46:41PM -0800, David Rientjes wrote:
> On Wed, 19 Feb 2014, Marcelo Tosatti wrote:
>
> > We agree that, in the future, we'd like to provide the ability to
> > dynamically allocate and free 1GB pages at runtime.
> >
> > Extending the
On Wed, Feb 19, 2014 at 07:46:41PM -0800, David Rientjes wrote:
> On Wed, 19 Feb 2014, Marcelo Tosatti wrote:
>
> > We agree that, in the future, we'd like to provide the ability to
> > dynamically allocate and free 1GB pages at runtime.
> >
> > Extending the
On Thu, Feb 20, 2014 at 03:15:46PM -0800, David Rientjes wrote:
> On Thu, 20 Feb 2014, Marcelo Tosatti wrote:
>
> > Mel has clearly has no objection to the command line. You can also
> > allocate 2M pages at runtime, and that is no reason for "hugepages="
On Fri, Feb 21, 2014 at 02:07:08AM -0800, David Rientjes wrote:
> On Thu, 20 Feb 2014, Marcelo Tosatti wrote:
>
> > > 1GB is of such granularity that you'd typically either be (a) oom so that
> > > your userspace couldn't even start, or (b) have enough memory s
t_pfn < level_pfn + level_size(level) - 1)) {
> dma_clear_pte(pte);
> domain_flush_cache(domain, pte, sizeof(*pte));
> free_pgtable_page(level_pte);
Reviewed-by: Marcelo Tosatti
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tue, Apr 01, 2014 at 12:17:16PM -0700, Andy Lutomirski wrote:
> On Tue, Apr 1, 2014 at 11:01 AM, Marcelo Tosatti wrote:
> > On Mon, Mar 31, 2014 at 10:33:41PM -0700, Andy Lutomirski wrote:
> >> On Mar 31, 2014 8:45 PM, "Marcelo Tosatti" wrote:
> >> >
&
801 - 900 of 1340 matches
Mail list logo
