On Thu, Nov 12, 2015 at 08:53:43PM +0900, Takuya Yoshikawa wrote:
> At some call sites of rmap_get_first() and rmap_get_next(), BUG_ON is
> placed right after the call to detect unrelated sptes which must not be
> found in the reverse-mapping list.
>
> Move this check in rmap_get_first/next() so
On Thu, Nov 12, 2015 at 08:52:45PM +0900, Takuya Yoshikawa wrote:
> kvm_mmu_mark_parents_unsync() alone uses pte_list_walk(), witch does
> nearly the same as the for_each_rmap_spte macro. The only difference
> is that is_shadow_present_pte() checks cannot be placed there because
>
On Fri, Nov 13, 2015 at 02:04:38PM -0500, Luiz Capitulino wrote:
> On Fri, 13 Nov 2015 15:27:40 -0200
> Marcelo Tosatti wrote:
>
> > On Fri, Nov 13, 2015 at 05:51:00PM +0100, Peter Zijlstra wrote:
> > > On Fri, Nov 13, 2015 at 02:39:33PM -0200, Marcelo Tosatti wrote:
>
On Fri, Nov 13, 2015 at 05:51:00PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 13, 2015 at 02:39:33PM -0200, Marcelo Tosatti wrote:
> > + * * one tcrid entry can be in different locations
> > + * in different sockets.
>
> NAK on that without cpuset i
On Fri, Nov 13, 2015 at 03:27:40PM -0200, Marcelo Tosatti wrote:
> On Fri, Nov 13, 2015 at 05:51:00PM +0100, Peter Zijlstra wrote:
> > On Fri, Nov 13, 2015 at 02:39:33PM -0200, Marcelo Tosatti wrote:
> > > + * * one tcrid entry can be in different locations
> > &g
On Fri, Nov 13, 2015 at 05:51:00PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 13, 2015 at 02:39:33PM -0200, Marcelo Tosatti wrote:
> > + * * one tcrid entry can be in different locations
> > + * in different sockets.
>
> NAK on that without cpuset i
On Fri, Nov 13, 2015 at 05:51:00PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 13, 2015 at 02:39:33PM -0200, Marcelo Tosatti wrote:
> > + * * one tcrid entry can be in different locations
> > + * in different sockets.
>
> NAK on that without cpuset i
Attached is an early version of the ioctl based CAT interface we
have been working on.
NOTE: it does not compile, there is no locking, but should
be sufficient for interested people to comment.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index db3622f..293726b 100644
---
On Fri, Nov 13, 2015 at 05:51:00PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 13, 2015 at 02:39:33PM -0200, Marcelo Tosatti wrote:
> > + * * one tcrid entry can be in different locations
> > + * in different sockets.
>
> NAK on that without cpuset i
Attached is an early version of the ioctl based CAT interface we
have been working on.
NOTE: it does not compile, there is no locking, but should
be sufficient for interested people to comment.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index db3622f..293726b 100644
---
On Fri, Nov 13, 2015 at 05:51:00PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 13, 2015 at 02:39:33PM -0200, Marcelo Tosatti wrote:
> > + * * one tcrid entry can be in different locations
> > + * in different sockets.
>
> NAK on that without cpuset i
On Fri, Nov 13, 2015 at 03:27:40PM -0200, Marcelo Tosatti wrote:
> On Fri, Nov 13, 2015 at 05:51:00PM +0100, Peter Zijlstra wrote:
> > On Fri, Nov 13, 2015 at 02:39:33PM -0200, Marcelo Tosatti wrote:
> > > + * * one tcrid entry can be in different locations
> > &g
On Fri, Nov 13, 2015 at 05:51:00PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 13, 2015 at 02:39:33PM -0200, Marcelo Tosatti wrote:
> > + * * one tcrid entry can be in different locations
> > + * in different sockets.
>
> NAK on that without cpuset i
On Thu, Nov 12, 2015 at 08:53:43PM +0900, Takuya Yoshikawa wrote:
> At some call sites of rmap_get_first() and rmap_get_next(), BUG_ON is
> placed right after the call to detect unrelated sptes which must not be
> found in the reverse-mapping list.
>
> Move this check in rmap_get_first/next() so
On Thu, Nov 12, 2015 at 08:52:45PM +0900, Takuya Yoshikawa wrote:
> kvm_mmu_mark_parents_unsync() alone uses pte_list_walk(), witch does
> nearly the same as the for_each_rmap_spte macro. The only difference
> is that is_shadow_present_pte() checks cannot be placed there because
>
On Fri, Nov 13, 2015 at 02:04:38PM -0500, Luiz Capitulino wrote:
> On Fri, 13 Nov 2015 15:27:40 -0200
> Marcelo Tosatti <mtosa...@redhat.com> wrote:
>
> > On Fri, Nov 13, 2015 at 05:51:00PM +0100, Peter Zijlstra wrote:
> > > On Fri, Nov 13, 2015 at 02:39:33P
On Fri, Oct 16, 2015 at 11:50:22AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 15, 2015 at 11:28:52PM -0300, Marcelo Tosatti wrote:
> > On Thu, Oct 15, 2015 at 01:36:14PM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 13, 2015 at 06:31:27PM -0300, Marcelo Tosatti wrote:
>
On Fri, Oct 16, 2015 at 11:50:22AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 15, 2015 at 11:28:52PM -0300, Marcelo Tosatti wrote:
> > On Thu, Oct 15, 2015 at 01:36:14PM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 13, 2015 at 06:31:27PM -0300, Marcelo Tosatti wrote:
>
On Wed, Oct 28, 2015 at 06:05:00PM +0100, Paolo Bonzini wrote:
>
>
> On 28/10/2015 17:00, Alex Williamson wrote:
> > > Alex, would it make sense to use the IRQ bypass infrastructure always,
> > > not just for VT-d, to do the MSI injection directly from the VFIO
> > > interrupt handler and bypass
On Wed, Oct 28, 2015 at 06:05:00PM +0100, Paolo Bonzini wrote:
>
>
> On 28/10/2015 17:00, Alex Williamson wrote:
> > > Alex, would it make sense to use the IRQ bypass infrastructure always,
> > > not just for VT-d, to do the MSI injection directly from the VFIO
> > > interrupt handler and bypass
Hi Peter,
On Fri, Oct 16, 2015 at 11:50:22AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 15, 2015 at 11:28:52PM -0300, Marcelo Tosatti wrote:
> > On Thu, Oct 15, 2015 at 01:36:14PM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 13, 2015 at 06:31:27PM -0300, Marcelo Tosatti w
Hi Peter,
On Fri, Oct 16, 2015 at 11:50:22AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 15, 2015 at 11:28:52PM -0300, Marcelo Tosatti wrote:
> > On Thu, Oct 15, 2015 at 01:36:14PM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 13, 2015 at 06:31:27PM -0300, Marcelo Tosatti w
On Fri, Oct 16, 2015 at 05:24:42PM -0300, Marcelo Tosatti wrote:
> On Fri, Oct 16, 2015 at 11:44:52AM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 15, 2015 at 09:17:16PM -0300, Marcelo Tosatti wrote:
> > > On Thu, Oct 15, 2015 at 01:37:02PM +0200, Peter Zijlstra wrote:
> >
On Fri, Oct 16, 2015 at 11:44:52AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 15, 2015 at 09:17:16PM -0300, Marcelo Tosatti wrote:
> > On Thu, Oct 15, 2015 at 01:37:02PM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 13, 2015 at 07:40:58PM -0300, Marcelo Tosatti wrote:
>
On Fri, Oct 16, 2015 at 11:44:52AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 15, 2015 at 09:17:16PM -0300, Marcelo Tosatti wrote:
> > On Thu, Oct 15, 2015 at 01:37:02PM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 13, 2015 at 07:40:58PM -0300, Marcelo Tosatti wrote:
>
On Fri, Oct 16, 2015 at 05:24:42PM -0300, Marcelo Tosatti wrote:
> On Fri, Oct 16, 2015 at 11:44:52AM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 15, 2015 at 09:17:16PM -0300, Marcelo Tosatti wrote:
> > > On Thu, Oct 15, 2015 at 01:37:02PM +0200, Peter Zijlstra wrote:
> >
On Thu, Oct 15, 2015 at 01:36:14PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 13, 2015 at 06:31:27PM -0300, Marcelo Tosatti wrote:
> > I am rewriting the interface with ioctls, with commands similar to the
> > syscall interface proposed.
>
> Which is horrible for other use
On Thu, Oct 15, 2015 at 01:37:02PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 13, 2015 at 07:40:58PM -0300, Marcelo Tosatti wrote:
> > How can you fix the issue of sockets with different reserved cache
> > regions with hw in the cgroup interface?
>
> No idea what you're ref
On Thu, Oct 15, 2015 at 01:37:02PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 13, 2015 at 07:40:58PM -0300, Marcelo Tosatti wrote:
> > How can you fix the issue of sockets with different reserved cache
> > regions with hw in the cgroup interface?
>
> No idea what you're ref
On Thu, Oct 15, 2015 at 01:36:14PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 13, 2015 at 06:31:27PM -0300, Marcelo Tosatti wrote:
> > I am rewriting the interface with ioctls, with commands similar to the
> > syscall interface proposed.
>
> Which is horrible for other use
On Sun, Oct 11, 2015 at 09:50:12PM +0200, Thomas Gleixner wrote:
> Fenghua,
>
> On Thu, 1 Oct 2015, Fenghua Yu wrote:
>
> +Cc: Marcelo
>
> > This series has some preparatory patches and Intel cache allocation
> > support.
>
>
>
> > Changes in v15:
> > - Add a global IPI to update the closid
On Mon, Oct 12, 2015 at 06:52:49PM +, Yu, Fenghua wrote:
> > From: Thomas Gleixner [mailto:t...@linutronix.de]
> > Sent: Sunday, October 11, 2015 12:50 PM
> > To: Yu, Fenghua
> > Cc: H Peter Anvin; Ingo Molnar; Peter Zijlstra; linux-kernel; x86; Vikas
> > Shivapp
On Sun, Oct 11, 2015 at 09:50:12PM +0200, Thomas Gleixner wrote:
> Fenghua,
>
> On Thu, 1 Oct 2015, Fenghua Yu wrote:
>
> +Cc: Marcelo
>
> > This series has some preparatory patches and Intel cache allocation
> > support.
>
>
>
> > Changes in v15:
> > - Add a global IPI to update the closid
On Mon, Oct 12, 2015 at 06:52:49PM +, Yu, Fenghua wrote:
> > From: Thomas Gleixner [mailto:t...@linutronix.de]
> > Sent: Sunday, October 11, 2015 12:50 PM
> > To: Yu, Fenghua
> > Cc: H Peter Anvin; Ingo Molnar; Peter Zijlstra; linux-kernel; x86; Vikas
> > Shivapp
On Tue, Sep 22, 2015 at 09:52:49PM +0200, Paolo Bonzini wrote:
>
>
> On 22/09/2015 21:01, Marcelo Tosatti wrote:
> > On Fri, Sep 18, 2015 at 05:54:30PM +0200, Radim Krčmář wrote:
> >> Shifting pvclock_vcpu_time_info.system_time on write to KVM system time
> >>
On Tue, Sep 22, 2015 at 09:52:49PM +0200, Paolo Bonzini wrote:
>
>
> On 22/09/2015 21:01, Marcelo Tosatti wrote:
> > On Fri, Sep 18, 2015 at 05:54:30PM +0200, Radim Krčmář wrote:
> >> Shifting pvclock_vcpu_time_info.system_time on write to KVM system time
> >>
On Tue, Sep 22, 2015 at 06:33:46PM +0200, Radim Krčmář wrote:
> PVCLOCK_COUNTS_FROM_ZERO broke ABI and (at least) three things with it.
> All problems stem from repeated writes to MSR_KVM_SYSTEM_TIME(_NEW).
> The reverted patch treated the MSR write as a one-shot initializer:
> any write from VCPU
On Fri, Sep 18, 2015 at 05:54:30PM +0200, Radim Krčmář wrote:
> Shifting pvclock_vcpu_time_info.system_time on write to KVM system time
> MSR is a change of ABI. Probably only 2.6.16 based SLES 10 breaks due
> to its custom enhancements to kvmclock, but KVM never declared the MSR
> only for
On Fri, Sep 18, 2015 at 05:54:29PM +0200, Radim Krčmář wrote:
> Newer KVM won't be exposing PVCLOCK_COUNTS_FROM_ZERO anymore.
> The purpose of that flags was to start counting system time from 0 when
> the KVM clock has been initialized.
> We can achieve the same by selecting one read as the
On Tue, Sep 22, 2015 at 06:33:46PM +0200, Radim Krčmář wrote:
> PVCLOCK_COUNTS_FROM_ZERO broke ABI and (at least) three things with it.
> All problems stem from repeated writes to MSR_KVM_SYSTEM_TIME(_NEW).
> The reverted patch treated the MSR write as a one-shot initializer:
> any write from VCPU
On Fri, Sep 18, 2015 at 05:54:29PM +0200, Radim Krčmář wrote:
> Newer KVM won't be exposing PVCLOCK_COUNTS_FROM_ZERO anymore.
> The purpose of that flags was to start counting system time from 0 when
> the KVM clock has been initialized.
> We can achieve the same by selecting one read as the
On Fri, Sep 18, 2015 at 05:54:30PM +0200, Radim Krčmář wrote:
> Shifting pvclock_vcpu_time_info.system_time on write to KVM system time
> MSR is a change of ABI. Probably only 2.6.16 based SLES 10 breaks due
> to its custom enhancements to kvmclock, but KVM never declared the MSR
> only for
> So either:
>
> Proceed with guest solution:
> -> Make sure the overflow can't happen (and write down why not in the
> code). Don't assume a small delta between kvmclock values of vcpus.
> -> Handle stable -> non-stable kvmclock transition.
> -> kvmclock counts from zero should not depend on
On Tue, Sep 22, 2015 at 12:00:39AM +0200, Radim Krčmář wrote:
> 2015-09-21 17:53-0300, Marcelo Tosatti:
> > On Mon, Sep 21, 2015 at 10:00:27PM +0200, Radim Krčmář wrote:
> >> 2015-09-21 12:52-0300, Marcelo Tosatti:
> >> > On Mon, Sep 21, 2015 at 05:12:10PM +0200, Ra
On Mon, Sep 21, 2015 at 10:00:27PM +0200, Radim Krčmář wrote:
> 2015-09-21 12:52-0300, Marcelo Tosatti:
> > On Mon, Sep 21, 2015 at 05:12:10PM +0200, Radim Krčmář wrote:
> >> 2015-09-20 19:57-0300, Marcelo Tosatti:
> >>> Is it counting from zero that breaks SL
On Mon, Sep 21, 2015 at 05:12:10PM +0200, Radim Krčmář wrote:
> 2015-09-20 19:57-0300, Marcelo Tosatti:
> > On Fri, Sep 18, 2015 at 05:54:28PM +0200, Radim Krčmář wrote:
> >> This patch series will be disabling PVCLOCK_COUNTS_FROM_ZERO flag and is
> >> RFC because I have
On Tue, Sep 22, 2015 at 12:00:39AM +0200, Radim Krčmář wrote:
> 2015-09-21 17:53-0300, Marcelo Tosatti:
> > On Mon, Sep 21, 2015 at 10:00:27PM +0200, Radim Krčmář wrote:
> >> 2015-09-21 12:52-0300, Marcelo Tosatti:
> >> > On Mon, Sep 21, 2015 at 05:12:10PM +0200, Ra
> So either:
>
> Proceed with guest solution:
> -> Make sure the overflow can't happen (and write down why not in the
> code). Don't assume a small delta between kvmclock values of vcpus.
> -> Handle stable -> non-stable kvmclock transition.
> -> kvmclock counts from zero should not depend on
On Mon, Sep 21, 2015 at 05:12:10PM +0200, Radim Krčmář wrote:
> 2015-09-20 19:57-0300, Marcelo Tosatti:
> > On Fri, Sep 18, 2015 at 05:54:28PM +0200, Radim Krčmář wrote:
> >> This patch series will be disabling PVCLOCK_COUNTS_FROM_ZERO flag and is
> >> RFC because I have
On Mon, Sep 21, 2015 at 10:00:27PM +0200, Radim Krčmář wrote:
> 2015-09-21 12:52-0300, Marcelo Tosatti:
> > On Mon, Sep 21, 2015 at 05:12:10PM +0200, Radim Krčmář wrote:
> >> 2015-09-20 19:57-0300, Marcelo Tosatti:
> >>> Is it counting from zero that breaks SL
On Fri, Sep 18, 2015 at 05:54:28PM +0200, Radim Krčmář wrote:
> This patch series will be disabling PVCLOCK_COUNTS_FROM_ZERO flag and is
> RFC because I haven't explored many potential problems or tested it.
The justification to disable PVCLOCK_COUNTS_FROM_ZERO is because you
haven't explored
On Fri, Sep 18, 2015 at 05:54:28PM +0200, Radim Krčmář wrote:
> This patch series will be disabling PVCLOCK_COUNTS_FROM_ZERO flag and is
> RFC because I haven't explored many potential problems or tested it.
The justification to disable PVCLOCK_COUNTS_FROM_ZERO is because you
haven't explored
On Sun, Aug 23, 2015 at 11:47:49AM -0700, Vikas Shivappa wrote:
>
>
> On Fri, 21 Aug 2015, Marcelo Tosatti wrote:
>
> >On Thu, Aug 20, 2015 at 05:06:51PM -0700, Vikas Shivappa wrote:
> >>
> >>
> >>On Mon, 17 Aug 2015, Marcelo Tosatti wrote:
> >
On Sun, Aug 23, 2015 at 11:47:49AM -0700, Vikas Shivappa wrote:
On Fri, 21 Aug 2015, Marcelo Tosatti wrote:
On Thu, Aug 20, 2015 at 05:06:51PM -0700, Vikas Shivappa wrote:
On Mon, 17 Aug 2015, Marcelo Tosatti wrote:
Vikas, Tejun,
This is an updated interface. It addresses all
On Thu, Aug 20, 2015 at 05:06:51PM -0700, Vikas Shivappa wrote:
>
>
> On Mon, 17 Aug 2015, Marcelo Tosatti wrote:
>
> >Vikas, Tejun,
> >
> >This is an updated interface. It addresses all comments made
> >so far and also covers all use-cases the cgroup int
On Thu, Aug 20, 2015 at 05:06:51PM -0700, Vikas Shivappa wrote:
On Mon, 17 Aug 2015, Marcelo Tosatti wrote:
Vikas, Tejun,
This is an updated interface. It addresses all comments made
so far and also covers all use-cases the cgroup interface
covers.
Let me know what you think. I'll
Vikas, Tejun,
This is an updated interface. It addresses all comments made
so far and also covers all use-cases the cgroup interface
covers.
Let me know what you think. I'll proceed to writing
the test applications.
Usage model:
This document details how CAT technology is
Vikas, Tejun,
This is an updated interface. It addresses all comments made
so far and also covers all use-cases the cgroup interface
covers.
Let me know what you think. I'll proceed to writing
the test applications.
Usage model:
This document details how CAT technology is
On Thu, Aug 06, 2015 at 01:46:06PM -0700, Vikas Shivappa wrote:
>
>
> On Wed, 5 Aug 2015, Marcelo Tosatti wrote:
>
> >On Wed, Aug 05, 2015 at 01:22:57PM +0100, Matt Fleming wrote:
> >>On Sun, 02 Aug, at 12:31:57PM, Tejun Heo wrote:
> >>>
> >>>B
On Thu, Aug 06, 2015 at 01:46:06PM -0700, Vikas Shivappa wrote:
On Wed, 5 Aug 2015, Marcelo Tosatti wrote:
On Wed, Aug 05, 2015 at 01:22:57PM +0100, Matt Fleming wrote:
On Sun, 02 Aug, at 12:31:57PM, Tejun Heo wrote:
But we're doing it the wrong way around. You can do most of what
On Wed, Aug 05, 2015 at 01:22:57PM +0100, Matt Fleming wrote:
> On Sun, 02 Aug, at 12:31:57PM, Tejun Heo wrote:
> >
> > But we're doing it the wrong way around. You can do most of what
> > cgroup interface can do with systemcall-like interface with some
> > inconvenience. The other way doesn't
On Wed, Aug 05, 2015 at 01:22:57PM +0100, Matt Fleming wrote:
On Sun, 02 Aug, at 12:31:57PM, Tejun Heo wrote:
But we're doing it the wrong way around. You can do most of what
cgroup interface can do with systemcall-like interface with some
inconvenience. The other way doesn't really
On Mon, Aug 03, 2015 at 05:32:50PM -0300, Marcelo Tosatti wrote:
> On Sun, Aug 02, 2015 at 12:23:25PM -0400, Tejun Heo wrote:
> > Hello,
> >
> > On Fri, Jul 31, 2015 at 12:12:18PM -0300, Marcelo Tosatti wrote:
> > > > I don't really think it makes sense
On Mon, Aug 03, 2015 at 05:32:50PM -0300, Marcelo Tosatti wrote:
On Sun, Aug 02, 2015 at 12:23:25PM -0400, Tejun Heo wrote:
Hello,
On Fri, Jul 31, 2015 at 12:12:18PM -0300, Marcelo Tosatti wrote:
I don't really think it makes sense to implement a fully hierarchical
cgroup solution
On Sun, Aug 02, 2015 at 12:23:25PM -0400, Tejun Heo wrote:
> Hello,
>
> On Fri, Jul 31, 2015 at 12:12:18PM -0300, Marcelo Tosatti wrote:
> > > I don't really think it makes sense to implement a fully hierarchical
> > > cgroup solution when there isn't the basic affinit
On Sun, Aug 02, 2015 at 05:48:07PM +0200, Martin Kletzander wrote:
> On Thu, Jul 30, 2015 at 05:08:13PM -0300, Marcelo Tosatti wrote:
> >On Thu, Jul 30, 2015 at 10:47:23AM -0700, Vikas Shivappa wrote:
> >>
> >>
> >>Marcello,
> >>
> >>
> >
On Sun, Aug 02, 2015 at 12:23:25PM -0400, Tejun Heo wrote:
Hello,
On Fri, Jul 31, 2015 at 12:12:18PM -0300, Marcelo Tosatti wrote:
I don't really think it makes sense to implement a fully hierarchical
cgroup solution when there isn't the basic affinity-adjusting
interface
What
On Sun, Aug 02, 2015 at 05:48:07PM +0200, Martin Kletzander wrote:
On Thu, Jul 30, 2015 at 05:08:13PM -0300, Marcelo Tosatti wrote:
On Thu, Jul 30, 2015 at 10:47:23AM -0700, Vikas Shivappa wrote:
Marcello,
On Wed, 29 Jul 2015, Marcelo Tosatti wrote:
How about this:
desiredclos
very confusing for the user if he
> has allocated a cache mask and suddenly from under the floor the
> kernel changes it.
Agree.
>
> Thanks,
> Vikas
>
>
> On Fri, 31 Jul 2015, Marcelo Tosatti wrote:
>
> >On Thu, Jul 30, 2015 at 04:03:07PM -0700
On Thu, Jul 30, 2015 at 05:08:13PM -0300, Marcelo Tosatti wrote:
> On Thu, Jul 30, 2015 at 10:47:23AM -0700, Vikas Shivappa wrote:
> >
> >
> > Marcello,
> >
> >
> > On Wed, 29 Jul 2015, Marcelo Tosatti wrote:
> > >
> > >How
On Thu, Jul 30, 2015 at 04:03:07PM -0700, Vikas Shivappa wrote:
>
>
> On Thu, 30 Jul 2015, Marcelo Tosatti wrote:
>
> >On Thu, Jul 30, 2015 at 10:47:23AM -0700, Vikas Shivappa wrote:
> >>
> >>
> >>Marcello,
> >>
> >>
>
On Thu, Jul 30, 2015 at 03:44:58PM -0400, Tejun Heo wrote:
> Hello, Vikas.
>
> On Wed, Jul 01, 2015 at 03:21:06PM -0700, Vikas Shivappa wrote:
> > This patch adds a cgroup subsystem for Intel Resource Director
> > Technology(RDT) feature and Class of service(CLOSid) management which is
> > part
On Thu, Jul 30, 2015 at 04:03:07PM -0700, Vikas Shivappa wrote:
On Thu, 30 Jul 2015, Marcelo Tosatti wrote:
On Thu, Jul 30, 2015 at 10:47:23AM -0700, Vikas Shivappa wrote:
Marcello,
On Wed, 29 Jul 2015, Marcelo Tosatti wrote:
How about this:
desiredclos (closid p1 p2 p3
On Thu, Jul 30, 2015 at 03:44:58PM -0400, Tejun Heo wrote:
Hello, Vikas.
On Wed, Jul 01, 2015 at 03:21:06PM -0700, Vikas Shivappa wrote:
This patch adds a cgroup subsystem for Intel Resource Director
Technology(RDT) feature and Class of service(CLOSid) management which is
part of common
On Thu, Jul 30, 2015 at 05:08:13PM -0300, Marcelo Tosatti wrote:
On Thu, Jul 30, 2015 at 10:47:23AM -0700, Vikas Shivappa wrote:
Marcello,
On Wed, 29 Jul 2015, Marcelo Tosatti wrote:
How about this:
desiredclos (closid p1 p2 p3 p4)
1 1 0 0 0
if we can avoid it.
This interface lets the super-user control
the cache allocation and it may be very confusing for the user if he
has allocated a cache mask and suddenly from under the floor the
kernel changes it.
Agree.
Thanks,
Vikas
On Fri, 31 Jul 2015, Marcelo Tosatti wrote
On Thu, Jul 30, 2015 at 10:47:23AM -0700, Vikas Shivappa wrote:
>
>
> Marcello,
>
>
> On Wed, 29 Jul 2015, Marcelo Tosatti wrote:
> >
> >How about this:
> >
> >desiredclos (closid p1 p2 p3 p4)
> > 1 1 0 0 0
> >
On Thu, Jul 30, 2015 at 10:47:23AM -0700, Vikas Shivappa wrote:
>
>
> Marcello,
>
>
> On Wed, 29 Jul 2015, Marcelo Tosatti wrote:
> >
> >How about this:
> >
> >desiredclos (closid p1 p2 p3 p4)
> > 1 1 0 0 0
> >
On Thu, Jul 30, 2015 at 10:47:23AM -0700, Vikas Shivappa wrote:
Marcello,
On Wed, 29 Jul 2015, Marcelo Tosatti wrote:
How about this:
desiredclos (closid p1 p2 p3 p4)
1 1 0 0 0
2 0 0 0 1
3 0 1 1 0
#1 Currently
On Thu, Jul 30, 2015 at 10:47:23AM -0700, Vikas Shivappa wrote:
Marcello,
On Wed, 29 Jul 2015, Marcelo Tosatti wrote:
How about this:
desiredclos (closid p1 p2 p3 p4)
1 1 0 0 0
2 0 0 0 1
3 0 1 1 0
#1 Currently
On Wed, Jul 29, 2015 at 01:28:38AM +, Auld, Will wrote:
> > > Whenever cgroupE has zero tasks, remove exclusivity (by allowing other
> > > cgroups to use the exclusive ways of it).
> >
> > Same comment as above - Cgroup masks can always overlap and other cgroups
> > can allocate the same
On Wed, Jul 29, 2015 at 01:28:38AM +, Auld, Will wrote:
Whenever cgroupE has zero tasks, remove exclusivity (by allowing other
cgroups to use the exclusive ways of it).
Same comment as above - Cgroup masks can always overlap and other cgroups
can allocate the same cache , and
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.shares is
On Wed, Jul 01, 2015 at 03:21:04PM -0700, Vikas Shivappa wrote:
> Adds a description of Cache allocation technology, overview
> of kernel implementation and usage of Cache Allocation cgroup interface.
>
> Cache allocation is a sub-feature of Resource Director Technology(RDT)
> Allocation or
On Wed, Jul 01, 2015 at 03:21:04PM -0700, Vikas Shivappa wrote:
Adds a description of Cache allocation technology, overview
of kernel implementation and usage of Cache Allocation cgroup interface.
Cache allocation is a sub-feature of Resource Director Technology(RDT)
Allocation or Platform
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.shares is written in ratio form, which is much more natural.
Do
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
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
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..
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...@redhat.com; x...@kernel.org;
g...@kernel.org
Initialize kvmclock base, on kvmclock system MSR write time,
so that the guest sees kvmclock counting from zero.
This matches baremetal behaviour when kvmclock in guest
sets sched clock stable.
Signed-off-by: Marcelo Tosatti
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index cc2c759
Initialize kvmclock base, on kvmclock system MSR write time,
so that the guest sees kvmclock counting from zero.
This matches baremetal behaviour when kvmclock in guest
sets sched clock stable.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm
On Mon, May 18, 2015 at 10:13:03PM -0400, Sasha Levin wrote:
> On 05/18/2015 10:02 PM, Sasha Levin wrote:
> > On 05/18/2015 08:13 PM, Marcelo Tosatti wrote:
> >> GOn Mon, May 18, 2015 at 07:45:41PM -0400, Sasha Levin wrote:
> >>>> On 05/18/2015 06:39 PM, Marcelo To
Initialize kvmclock base, on kvmclock system MSR write time,
so that the guest sees kvmclock counting from zero.
This matches baremetal behaviour when kvmclock in guest
sets sched clock stable.
Signed-off-by: Marcelo Tosatti
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index cc2c759
On Mon, May 18, 2015 at 10:13:03PM -0400, Sasha Levin wrote:
On 05/18/2015 10:02 PM, Sasha Levin wrote:
On 05/18/2015 08:13 PM, Marcelo Tosatti wrote:
GOn Mon, May 18, 2015 at 07:45:41PM -0400, Sasha Levin wrote:
On 05/18/2015 06:39 PM, Marcelo Tosatti wrote:
On Tue, May 12, 2015 at 07:17
Initialize kvmclock base, on kvmclock system MSR write time,
so that the guest sees kvmclock counting from zero.
This matches baremetal behaviour when kvmclock in guest
sets sched clock stable.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm
GOn Mon, May 18, 2015 at 07:45:41PM -0400, Sasha Levin wrote:
> On 05/18/2015 06:39 PM, Marcelo Tosatti wrote:
> > On Tue, May 12, 2015 at 07:17:24PM -0400, Sasha Levin wrote:
> >> Hi all,
> >>
> >> I'm seeing odd jump in time values during boot of a KVM guest
On Tue, May 12, 2015 at 07:17:24PM -0400, Sasha Levin wrote:
> Hi all,
>
> I'm seeing odd jump in time values during boot of a KVM guest:
>
> [...]
> [0.00] tsc: Detected 2260.998 MHz processor
> [3376355.247558] Calibrating delay loop (skipped) preset value..
> [...]
>
> I've bisected
On Tue, May 12, 2015 at 07:17:24PM -0400, Sasha Levin wrote:
Hi all,
I'm seeing odd jump in time values during boot of a KVM guest:
[...]
[0.00] tsc: Detected 2260.998 MHz processor
[3376355.247558] Calibrating delay loop (skipped) preset value..
[...]
I've bisected it to:
GOn Mon, May 18, 2015 at 07:45:41PM -0400, Sasha Levin wrote:
On 05/18/2015 06:39 PM, Marcelo Tosatti wrote:
On Tue, May 12, 2015 at 07:17:24PM -0400, Sasha Levin wrote:
Hi all,
I'm seeing odd jump in time values during boot of a KVM guest:
[...]
[0.00] tsc: Detected
501 - 600 of 2527 matches
Mail list logo
