From: paulmck at linux.ibm.com (Paul E. McKenney)
Subject: [PATCH] rcutorture: Tweak kvm options
Date: Fri, 26 Apr 2019 06:50:58 -0700 [thread overview]
Message-ID: <20190426135058.GD3923@linux.ibm.com> (raw)
In-Reply-To: <20190426105413.rajcon4vyzov446c@linutronix.de>
On Fri, Apr 26, 2019 at 12:54:14PM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-04-25 12:46:38 [-0700], Paul E. McKenney wrote:
> > > And it doesn't like my (admittedly ancient) QEMU, complaining about not
> > > knowing about "x2apic=on,tsc-deadline=on,hypervisor=on,tsc_adjust=on".
> > > If I remove these, it works. I will be upgrading soon (famous last
> > > words), so what I am going to do is queue the following separate
> > > not-for-upstream patch that makes it work on my setup.
> >
> > Also, the !SMP scenarios get this:
> >
> > :CONFIG_PARAVIRT_SPINLOCKS=y: improperly set
>
> I ignored that (because there is a CHECK option to ensure that certain
> options are set).
True enough, but these things are a bit like compiler warnings in that
it is good to have a clean run.
> > Would it make sense to only set this on CONFIG_SMP=y runs? The easy
> > way to do this is to move it from CFcommon to the scenario files not
> > having CONFIG_SMP=n.
(Which is how I am currently running, I should have added.)
> > having CONFIG_SMP=n. Or would something else work better?
> >
> > Or am I doing something wrong?
>
> You should also get that warning on ARM for instance since those
> PARAVIRT SPINLOCKS are only implemented on x86.
OK, so we would want this to only be added for x86 runs.
> I have no numbers to compare the performance with and without that
> option. So we could drop that option or you tell me where to look after
> a run with/without that option so I can tell if it is worth the effort.
One place to look is in the summary output:
TREE01 ------- 17540 GPs (58.4667/s) [rcu: g130629 f0x0 ]
The "58.4667/s" is the number of grace periods per second. I would be
surprised if CONFIG_PARAVIRT_SPINLOCKS made a noticeable difference in
grace-period rate (given the natural variation), but you never know.
Thanx, Paul
WARNING: multiple messages have this Message-ID (diff)
From: paulmck@linux.ibm.com (Paul E. McKenney)
Subject: [PATCH] rcutorture: Tweak kvm options
Date: Fri, 26 Apr 2019 06:50:58 -0700 [thread overview]
Message-ID: <20190426135058.GD3923@linux.ibm.com> (raw)
Message-ID: <20190426135058.mKtwXOvZCyDO70UHHtOdXXPmyS3yGgb3Mv4E0ESWkak@z> (raw)
In-Reply-To: <20190426105413.rajcon4vyzov446c@linutronix.de>
On Fri, Apr 26, 2019@12:54:14PM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-04-25 12:46:38 [-0700], Paul E. McKenney wrote:
> > > And it doesn't like my (admittedly ancient) QEMU, complaining about not
> > > knowing about "x2apic=on,tsc-deadline=on,hypervisor=on,tsc_adjust=on".
> > > If I remove these, it works. I will be upgrading soon (famous last
> > > words), so what I am going to do is queue the following separate
> > > not-for-upstream patch that makes it work on my setup.
> >
> > Also, the !SMP scenarios get this:
> >
> > :CONFIG_PARAVIRT_SPINLOCKS=y: improperly set
>
> I ignored that (because there is a CHECK option to ensure that certain
> options are set).
True enough, but these things are a bit like compiler warnings in that
it is good to have a clean run.
> > Would it make sense to only set this on CONFIG_SMP=y runs? The easy
> > way to do this is to move it from CFcommon to the scenario files not
> > having CONFIG_SMP=n.
(Which is how I am currently running, I should have added.)
> > having CONFIG_SMP=n. Or would something else work better?
> >
> > Or am I doing something wrong?
>
> You should also get that warning on ARM for instance since those
> PARAVIRT SPINLOCKS are only implemented on x86.
OK, so we would want this to only be added for x86 runs.
> I have no numbers to compare the performance with and without that
> option. So we could drop that option or you tell me where to look after
> a run with/without that option so I can tell if it is worth the effort.
One place to look is in the summary output:
TREE01 ------- 17540 GPs (58.4667/s) [rcu: g130629 f0x0 ]
The "58.4667/s" is the number of grace periods per second. I would be
surprised if CONFIG_PARAVIRT_SPINLOCKS made a noticeable difference in
grace-period rate (given the natural variation), but you never know.
Thanx, Paul
WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-kselftest@vger.kernel.org, rcu@vger.kernel.org,
Josh Triplett <josh@joshtriplett.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Shuah Khan <shuah@kernel.org>
Subject: Re: [PATCH] rcutorture: Tweak kvm options
Date: Fri, 26 Apr 2019 06:50:58 -0700 [thread overview]
Message-ID: <20190426135058.GD3923@linux.ibm.com> (raw)
In-Reply-To: <20190426105413.rajcon4vyzov446c@linutronix.de>
On Fri, Apr 26, 2019 at 12:54:14PM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-04-25 12:46:38 [-0700], Paul E. McKenney wrote:
> > > And it doesn't like my (admittedly ancient) QEMU, complaining about not
> > > knowing about "x2apic=on,tsc-deadline=on,hypervisor=on,tsc_adjust=on".
> > > If I remove these, it works. I will be upgrading soon (famous last
> > > words), so what I am going to do is queue the following separate
> > > not-for-upstream patch that makes it work on my setup.
> >
> > Also, the !SMP scenarios get this:
> >
> > :CONFIG_PARAVIRT_SPINLOCKS=y: improperly set
>
> I ignored that (because there is a CHECK option to ensure that certain
> options are set).
True enough, but these things are a bit like compiler warnings in that
it is good to have a clean run.
> > Would it make sense to only set this on CONFIG_SMP=y runs? The easy
> > way to do this is to move it from CFcommon to the scenario files not
> > having CONFIG_SMP=n.
(Which is how I am currently running, I should have added.)
> > having CONFIG_SMP=n. Or would something else work better?
> >
> > Or am I doing something wrong?
>
> You should also get that warning on ARM for instance since those
> PARAVIRT SPINLOCKS are only implemented on x86.
OK, so we would want this to only be added for x86 runs.
> I have no numbers to compare the performance with and without that
> option. So we could drop that option or you tell me where to look after
> a run with/without that option so I can tell if it is worth the effort.
One place to look is in the summary output:
TREE01 ------- 17540 GPs (58.4667/s) [rcu: g130629 f0x0 ]
The "58.4667/s" is the number of grace periods per second. I would be
surprised if CONFIG_PARAVIRT_SPINLOCKS made a noticeable difference in
grace-period rate (given the natural variation), but you never know.
Thanx, Paul
next prev parent reply other threads:[~2019-04-26 13:50 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-24 7:34 [PATCH] rcutorture: Tweak kvm options bigeasy
2019-04-24 7:34 ` Sebastian Andrzej Siewior
2019-04-24 7:34 ` Sebastian Andrzej Siewior
2019-04-24 10:38 ` paulmck
2019-04-24 10:38 ` Paul E. McKenney
2019-04-24 10:38 ` Paul E. McKenney
2019-04-24 18:30 ` paulmck
2019-04-24 18:30 ` Paul E. McKenney
2019-04-24 18:30 ` Paul E. McKenney
2019-04-25 19:46 ` paulmck
2019-04-25 19:46 ` Paul E. McKenney
2019-04-25 19:46 ` Paul E. McKenney
2019-04-26 10:54 ` bigeasy
2019-04-26 10:54 ` Sebastian Andrzej Siewior
2019-04-26 10:54 ` Sebastian Andrzej Siewior
2019-04-26 13:50 ` paulmck [this message]
2019-04-26 13:50 ` Paul E. McKenney
2019-04-26 13:50 ` Paul E. McKenney
2019-04-29 8:19 ` bigeasy
2019-04-29 8:19 ` Sebastian Andrzej Siewior
2019-04-29 8:19 ` Sebastian Andrzej Siewior
2019-04-29 14:49 ` paulmck
2019-04-29 14:49 ` Paul E. McKenney
2019-04-29 14:49 ` Paul E. McKenney
2019-04-29 15:06 ` paulmck
2019-04-29 15:06 ` Paul E. McKenney
2019-04-29 15:06 ` Paul E. McKenney
2019-05-02 18:41 ` paulmck
2019-05-02 18:41 ` Paul E. McKenney
2019-05-02 18:41 ` Paul E. McKenney
2019-05-03 7:26 ` bigeasy
2019-05-03 7:26 ` Sebastian Andrzej Siewior
2019-05-03 7:26 ` Sebastian Andrzej Siewior
2019-04-25 16:45 ` joel
2019-04-25 16:45 ` Joel Fernandes
2019-04-25 16:45 ` Joel Fernandes
2019-04-25 17:13 ` bigeasy
2019-04-25 17:13 ` Sebastian Andrzej Siewior
2019-04-25 17:13 ` Sebastian Andrzej Siewior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190426135058.GD3923@linux.ibm.com \
--to=unknown@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.