On 05/18/2015 10:30 PM, Mike Galbraith wrote:
> On Mon, 2015-05-18 at 10:52 -0400, Rik van Riel wrote:
>
>> For real time KVM, it is desirable to run the VCPU threads on
>> isolated CPUs as real time tasks.
>>
>> Meanwhile, the emulator threads can run as normal tasks anywhere
>> on the system.
On 05/18/2015 10:30 PM, Mike Galbraith wrote:
On Mon, 2015-05-18 at 10:52 -0400, Rik van Riel wrote:
For real time KVM, it is desirable to run the VCPU threads on
isolated CPUs as real time tasks.
Meanwhile, the emulator threads can run as normal tasks anywhere
on the system.
This means
On Fri, 2015-05-22 at 16:39 +0200, Frederic Weisbecker wrote:
> On Thu, May 21, 2015 at 08:59:38PM +0200, Mike Galbraith wrote:
> > I think it's a mistake to make any rash assumption and/or mandate that
> > the user WILL use nohz_full CPUs immediately, or even at all for that
> > matter.
On Thu, May 21, 2015 at 08:59:38PM +0200, Mike Galbraith wrote:
> I think it's a mistake to make any rash assumption and/or mandate that
> the user WILL use nohz_full CPUs immediately, or even at all for that
> matter. nohz_full currently is nothing but a CPU attribute, period,
> nothing more,
On Thu, May 21, 2015 at 08:59:38PM +0200, Mike Galbraith wrote:
I think it's a mistake to make any rash assumption and/or mandate that
the user WILL use nohz_full CPUs immediately, or even at all for that
matter. nohz_full currently is nothing but a CPU attribute, period,
nothing more,
On Fri, 2015-05-22 at 16:39 +0200, Frederic Weisbecker wrote:
On Thu, May 21, 2015 at 08:59:38PM +0200, Mike Galbraith wrote:
I think it's a mistake to make any rash assumption and/or mandate that
the user WILL use nohz_full CPUs immediately, or even at all for that
matter. nohz_full
On Thu, 2015-05-21 at 15:06 +0200, Frederic Weisbecker wrote:
> On Thu, May 21, 2015 at 05:57:59AM -0700, Paul E. McKenney wrote:
> > On Thu, May 21, 2015 at 05:42:46PM +0530, Afzal Mohammed wrote:
> > > Hi,
> > >
> > > On Wed, May 20, 2015 at 02:00:26PM -0700, Paul E. McKenney wrote:
> > >
> >
On Thu, May 21, 2015 at 07:14:09AM -0700, Paul E. McKenney wrote:
> On Thu, May 21, 2015 at 06:59:05PM +0530, Afzal Mohammed wrote:
> > Hi,
> >
> > On Thu, May 21, 2015 at 03:06:23PM +0200, Frederic Weisbecker wrote:
> > > On Thu, May 21, 2015 at 05:57:59AM -0700, Paul E. McKenney wrote:
> >
> >
On Thu, May 21, 2015 at 06:59:05PM +0530, Afzal Mohammed wrote:
> Hi,
>
> On Thu, May 21, 2015 at 03:06:23PM +0200, Frederic Weisbecker wrote:
> > On Thu, May 21, 2015 at 05:57:59AM -0700, Paul E. McKenney wrote:
>
> > > Indeed, NO_HZ_FULL is special purpose. You normally would select
> > >
Hi,
On Thu, May 21, 2015 at 03:06:23PM +0200, Frederic Weisbecker wrote:
> On Thu, May 21, 2015 at 05:57:59AM -0700, Paul E. McKenney wrote:
> > Indeed, NO_HZ_FULL is special purpose. You normally would select
> > NO_HZ_FULL_ALL only on a system intended for heavy compute without
> >
On Thu, May 21, 2015 at 03:06:23PM +0200, Frederic Weisbecker wrote:
> On Thu, May 21, 2015 at 05:57:59AM -0700, Paul E. McKenney wrote:
> > On Thu, May 21, 2015 at 05:42:46PM +0530, Afzal Mohammed wrote:
> > > Hi,
> > >
> > > On Wed, May 20, 2015 at 02:00:26PM -0700, Paul E. McKenney wrote:
> >
On Thu, May 21, 2015 at 05:57:59AM -0700, Paul E. McKenney wrote:
> On Thu, May 21, 2015 at 05:42:46PM +0530, Afzal Mohammed wrote:
> > Hi,
> >
> > On Wed, May 20, 2015 at 02:00:26PM -0700, Paul E. McKenney wrote:
> >
> > > > > Given that kernel initiated association to isolcpus, a user turning
On Thu, May 21, 2015 at 05:42:46PM +0530, Afzal Mohammed wrote:
> Hi,
>
> On Wed, May 20, 2015 at 02:00:26PM -0700, Paul E. McKenney wrote:
>
> > > > Given that kernel initiated association to isolcpus, a user turning
> > > > NO_HZ_FULL_ALL on had better not have much generic load to manage. If
Hi,
On Wed, May 20, 2015 at 02:00:26PM -0700, Paul E. McKenney wrote:
> > > Given that kernel initiated association to isolcpus, a user turning
> > > NO_HZ_FULL_ALL on had better not have much generic load to manage. If
> >
> > On a quad-core desktop system with NO_HZ_FULL_ALL, hackbench took
On Thu, 2015-05-21 at 15:06 +0200, Frederic Weisbecker wrote:
On Thu, May 21, 2015 at 05:57:59AM -0700, Paul E. McKenney wrote:
On Thu, May 21, 2015 at 05:42:46PM +0530, Afzal Mohammed wrote:
Hi,
On Wed, May 20, 2015 at 02:00:26PM -0700, Paul E. McKenney wrote:
Given that
Hi,
On Wed, May 20, 2015 at 02:00:26PM -0700, Paul E. McKenney wrote:
Given that kernel initiated association to isolcpus, a user turning
NO_HZ_FULL_ALL on had better not have much generic load to manage. If
On a quad-core desktop system with NO_HZ_FULL_ALL, hackbench took 3x
time
On Thu, May 21, 2015 at 05:42:46PM +0530, Afzal Mohammed wrote:
Hi,
On Wed, May 20, 2015 at 02:00:26PM -0700, Paul E. McKenney wrote:
Given that kernel initiated association to isolcpus, a user turning
NO_HZ_FULL_ALL on had better not have much generic load to manage. If
On a
On Thu, May 21, 2015 at 05:57:59AM -0700, Paul E. McKenney wrote:
On Thu, May 21, 2015 at 05:42:46PM +0530, Afzal Mohammed wrote:
Hi,
On Wed, May 20, 2015 at 02:00:26PM -0700, Paul E. McKenney wrote:
Given that kernel initiated association to isolcpus, a user turning
On Thu, May 21, 2015 at 07:14:09AM -0700, Paul E. McKenney wrote:
On Thu, May 21, 2015 at 06:59:05PM +0530, Afzal Mohammed wrote:
Hi,
On Thu, May 21, 2015 at 03:06:23PM +0200, Frederic Weisbecker wrote:
On Thu, May 21, 2015 at 05:57:59AM -0700, Paul E. McKenney wrote:
Indeed,
On Thu, May 21, 2015 at 03:06:23PM +0200, Frederic Weisbecker wrote:
On Thu, May 21, 2015 at 05:57:59AM -0700, Paul E. McKenney wrote:
On Thu, May 21, 2015 at 05:42:46PM +0530, Afzal Mohammed wrote:
Hi,
On Wed, May 20, 2015 at 02:00:26PM -0700, Paul E. McKenney wrote:
Given
Hi,
On Thu, May 21, 2015 at 03:06:23PM +0200, Frederic Weisbecker wrote:
On Thu, May 21, 2015 at 05:57:59AM -0700, Paul E. McKenney wrote:
Indeed, NO_HZ_FULL is special purpose. You normally would select
NO_HZ_FULL_ALL only on a system intended for heavy compute without
normal-workload
On Thu, May 21, 2015 at 06:59:05PM +0530, Afzal Mohammed wrote:
Hi,
On Thu, May 21, 2015 at 03:06:23PM +0200, Frederic Weisbecker wrote:
On Thu, May 21, 2015 at 05:57:59AM -0700, Paul E. McKenney wrote:
Indeed, NO_HZ_FULL is special purpose. You normally would select
NO_HZ_FULL_ALL
On Thu, May 21, 2015 at 02:08:09AM +0530, Afzal Mohammed wrote:
> Hi,
>
> On Sun, May 17, 2015 at 07:30:50AM +0200, Mike Galbraith wrote:
>
> > Yeah, tying nohz_full set to isolcpus set up an initial condition that
> > you have to tear down with cpusets if you want those cpus returned to
> > the
Hi,
On Sun, May 17, 2015 at 07:30:50AM +0200, Mike Galbraith wrote:
> Yeah, tying nohz_full set to isolcpus set up an initial condition that
> you have to tear down with cpusets if you want those cpus returned to
> the general purpose pool. I had considered the kernel setting initial
> state to
On Thu, May 21, 2015 at 02:08:09AM +0530, Afzal Mohammed wrote:
Hi,
On Sun, May 17, 2015 at 07:30:50AM +0200, Mike Galbraith wrote:
Yeah, tying nohz_full set to isolcpus set up an initial condition that
you have to tear down with cpusets if you want those cpus returned to
the general
Hi,
On Sun, May 17, 2015 at 07:30:50AM +0200, Mike Galbraith wrote:
Yeah, tying nohz_full set to isolcpus set up an initial condition that
you have to tear down with cpusets if you want those cpus returned to
the general purpose pool. I had considered the kernel setting initial
state to be
On Mon, 2015-05-18 at 10:52 -0400, Rik van Riel wrote:
> For real time KVM, it is desirable to run the VCPU threads on
> isolated CPUs as real time tasks.
>
> Meanwhile, the emulator threads can run as normal tasks anywhere
> on the system.
>
> This means the /machine cpuset, which all guests
On 05/18/2015 10:22 AM, Mike Galbraith wrote:
> On Mon, 2015-05-18 at 10:07 -0400, Rik van Riel wrote:
>> On 05/17/2015 11:29 PM, Mike Galbraith wrote:
>>> On Sun, 2015-05-17 at 22:17 -0400, Rik van Riel wrote:
On 05/17/2015 01:30 AM, Mike Galbraith wrote:
> Given that kernel
On Mon, 2015-05-18 at 10:07 -0400, Rik van Riel wrote:
> On 05/17/2015 11:29 PM, Mike Galbraith wrote:
> > On Sun, 2015-05-17 at 22:17 -0400, Rik van Riel wrote:
> >> On 05/17/2015 01:30 AM, Mike Galbraith wrote:
> >>
> >>> Given that kernel initiated association to isolcpus, a user turning
> >>>
On 05/17/2015 11:29 PM, Mike Galbraith wrote:
> On Sun, 2015-05-17 at 22:17 -0400, Rik van Riel wrote:
>> On 05/17/2015 01:30 AM, Mike Galbraith wrote:
>>
>>> Given that kernel initiated association to isolcpus, a user turning
>>> NO_HZ_FULL_ALL on had better not have much generic load to manage.
On Mon, 2015-05-18 at 10:07 -0400, Rik van Riel wrote:
On 05/17/2015 11:29 PM, Mike Galbraith wrote:
On Sun, 2015-05-17 at 22:17 -0400, Rik van Riel wrote:
On 05/17/2015 01:30 AM, Mike Galbraith wrote:
Given that kernel initiated association to isolcpus, a user turning
NO_HZ_FULL_ALL on
On 05/18/2015 10:22 AM, Mike Galbraith wrote:
On Mon, 2015-05-18 at 10:07 -0400, Rik van Riel wrote:
On 05/17/2015 11:29 PM, Mike Galbraith wrote:
On Sun, 2015-05-17 at 22:17 -0400, Rik van Riel wrote:
On 05/17/2015 01:30 AM, Mike Galbraith wrote:
Given that kernel initiated association to
On 05/17/2015 11:29 PM, Mike Galbraith wrote:
On Sun, 2015-05-17 at 22:17 -0400, Rik van Riel wrote:
On 05/17/2015 01:30 AM, Mike Galbraith wrote:
Given that kernel initiated association to isolcpus, a user turning
NO_HZ_FULL_ALL on had better not have much generic load to manage. If
he/she
On Mon, 2015-05-18 at 10:52 -0400, Rik van Riel wrote:
For real time KVM, it is desirable to run the VCPU threads on
isolated CPUs as real time tasks.
Meanwhile, the emulator threads can run as normal tasks anywhere
on the system.
This means the /machine cpuset, which all guests live
On Sun, 2015-05-17 at 22:17 -0400, Rik van Riel wrote:
> On 05/17/2015 01:30 AM, Mike Galbraith wrote:
>
> > Given that kernel initiated association to isolcpus, a user turning
> > NO_HZ_FULL_ALL on had better not have much generic load to manage. If
> > he/she does not have CPUSETS enabled, or
On 05/17/2015 01:30 AM, Mike Galbraith wrote:
> Given that kernel initiated association to isolcpus, a user turning
> NO_HZ_FULL_ALL on had better not have much generic load to manage. If
> he/she does not have CPUSETS enabled, or should Rik's patch rendering
> isolcpus immutable be merged,
My
On Sun, 2015-05-17 at 22:17 -0400, Rik van Riel wrote:
On 05/17/2015 01:30 AM, Mike Galbraith wrote:
Given that kernel initiated association to isolcpus, a user turning
NO_HZ_FULL_ALL on had better not have much generic load to manage. If
he/she does not have CPUSETS enabled, or should
On 05/17/2015 01:30 AM, Mike Galbraith wrote:
Given that kernel initiated association to isolcpus, a user turning
NO_HZ_FULL_ALL on had better not have much generic load to manage. If
he/she does not have CPUSETS enabled, or should Rik's patch rendering
isolcpus immutable be merged,
My
On Sat, 2015-05-16 at 15:39 -0400, Sasha Levin wrote:
> On 05/06/2015 12:04 PM, Frederic Weisbecker wrote:
> > From: Chris Metcalf
> >
> > nohz_full is only useful with isolcpus also set, since otherwise the
> > scheduler has to run periodically to try to determine whether to steal
> > work from
On 05/06/2015 12:04 PM, Frederic Weisbecker wrote:
> From: Chris Metcalf
>
> nohz_full is only useful with isolcpus also set, since otherwise the
> scheduler has to run periodically to try to determine whether to steal
> work from other cores.
>
> Accordingly, when booting with nohz_full=xxx on
On 05/06/2015 12:04 PM, Frederic Weisbecker wrote:
From: Chris Metcalf cmetc...@ezchip.com
nohz_full is only useful with isolcpus also set, since otherwise the
scheduler has to run periodically to try to determine whether to steal
work from other cores.
Accordingly, when booting with
On Sat, 2015-05-16 at 15:39 -0400, Sasha Levin wrote:
On 05/06/2015 12:04 PM, Frederic Weisbecker wrote:
From: Chris Metcalf cmetc...@ezchip.com
nohz_full is only useful with isolcpus also set, since otherwise the
scheduler has to run periodically to try to determine whether to steal
From: Chris Metcalf
nohz_full is only useful with isolcpus also set, since otherwise the
scheduler has to run periodically to try to determine whether to steal
work from other cores.
Accordingly, when booting with nohz_full=xxx on the command line, we
should act as if isolcpus=xxx was also set,
From: Chris Metcalf cmetc...@ezchip.com
nohz_full is only useful with isolcpus also set, since otherwise the
scheduler has to run periodically to try to determine whether to steal
work from other cores.
Accordingly, when booting with nohz_full=xxx on the command line, we
should act as if
On Saturday 25 April 2015 19:13:10 Frederic Weisbecker wrote:
> On Fri, Apr 24, 2015 at 04:07:52PM -0400, Gene Heskett wrote:
> > On Friday 24 April 2015 11:58:31 Frederic Weisbecker wrote:
> > > From: Chris Metcalf
> > >
> > > nohz_full is only useful with isolcpus also set, since otherwise
> >
On Fri, Apr 24, 2015 at 04:07:52PM -0400, Gene Heskett wrote:
> On Friday 24 April 2015 11:58:31 Frederic Weisbecker wrote:
> > From: Chris Metcalf
> >
> > nohz_full is only useful with isolcpus also set, since otherwise the
> > scheduler has to run periodically to try to determine whether to
On Saturday 25 April 2015 19:13:10 Frederic Weisbecker wrote:
On Fri, Apr 24, 2015 at 04:07:52PM -0400, Gene Heskett wrote:
On Friday 24 April 2015 11:58:31 Frederic Weisbecker wrote:
From: Chris Metcalf cmetc...@ezchip.com
nohz_full is only useful with isolcpus also set, since
On Fri, Apr 24, 2015 at 04:07:52PM -0400, Gene Heskett wrote:
On Friday 24 April 2015 11:58:31 Frederic Weisbecker wrote:
From: Chris Metcalf cmetc...@ezchip.com
nohz_full is only useful with isolcpus also set, since otherwise the
scheduler has to run periodically to try to determine
On Friday 24 April 2015 11:58:31 Frederic Weisbecker wrote:
> From: Chris Metcalf
>
> nohz_full is only useful with isolcpus also set, since otherwise the
> scheduler has to run periodically to try to determine whether to steal
> work from other cores.
>
> Accordingly, when booting with
From: Chris Metcalf
nohz_full is only useful with isolcpus also set, since otherwise the
scheduler has to run periodically to try to determine whether to steal
work from other cores.
Accordingly, when booting with nohz_full=xxx on the command line, we
should act as if isolcpus=xxx was also set,
From: Chris Metcalf cmetc...@ezchip.com
nohz_full is only useful with isolcpus also set, since otherwise the
scheduler has to run periodically to try to determine whether to steal
work from other cores.
Accordingly, when booting with nohz_full=xxx on the command line, we
should act as if
On Friday 24 April 2015 11:58:31 Frederic Weisbecker wrote:
From: Chris Metcalf cmetc...@ezchip.com
nohz_full is only useful with isolcpus also set, since otherwise the
scheduler has to run periodically to try to determine whether to steal
work from other cores.
Accordingly, when booting
From: Chris Metcalf
nohz_full is only useful with isolcpus also set, since otherwise the
scheduler has to run periodically to try to determine whether to steal
work from other cores.
Accordingly, when booting with nohz_full=xxx on the command line, we
should act as if isolcpus=xxx was also set,
From: Chris Metcalf cmetc...@ezchip.com
nohz_full is only useful with isolcpus also set, since otherwise the
scheduler has to run periodically to try to determine whether to steal
work from other cores.
Accordingly, when booting with nohz_full=xxx on the command line, we
should act as if
54 matches
Mail list logo
