On Sun, Feb 22, 2015 at 10:31:26AM -0800, Arjan van de Ven wrote:
> >>To show the boot time, I'm using the timestamp of the "Write protecting"
> >>line,
> >>that's pretty much the last thing we print prior to ring 3 execution.
> >
> >That's a little sad; we ought to be write-protecting kernel
To show the boot time, I'm using the timestamp of the "Write protecting" line,
that's pretty much the last thing we print prior to ring 3 execution.
That's a little sad; we ought to be write-protecting kernel read-only
data as *early* as possible.
well... if you are compromised before the
To show the boot time, I'm using the timestamp of the Write protecting line,
that's pretty much the last thing we print prior to ring 3 execution.
That's a little sad; we ought to be write-protecting kernel read-only
data as *early* as possible.
well... if you are compromised before the
On Sun, Feb 22, 2015 at 10:31:26AM -0800, Arjan van de Ven wrote:
To show the boot time, I'm using the timestamp of the Write protecting
line,
that's pretty much the last thing we print prior to ring 3 execution.
That's a little sad; we ought to be write-protecting kernel read-only
data as
On Sat, Feb 21, 2015 at 07:58:07PM -0800, Josh Triplett wrote:
> On Sat, Feb 21, 2015 at 07:51:34AM -0800, Arjan van de Ven wrote:
> > >>
> > >>there's a few others as well that I'm chasing down...
> > >>.. but the flip side, prior to running ring 3 code, why NOT do fast
> > >>expedites?
> > >
>
On Sat, Feb 21, 2015 at 07:51:34AM -0800, Arjan van de Ven wrote:
> >>
> >>there's a few others as well that I'm chasing down...
> >>.. but the flip side, prior to running ring 3 code, why NOT do fast
> >>expedites?
> >
> >It would be good to have before-and-after measurements of actual
> >boot
On Sat, Feb 21, 2015 at 05:08:52PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 20, 2015 at 09:45:39AM -0800, Arjan van de Ven wrote:
> > On 2/20/2015 9:43 AM, Peter Zijlstra wrote:
> > >On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
> > >>there's a few others as well that I'm
y prani"
> >
> > Sent: Saturday, February 21, 2015 1:04:28 AM
> > Subject: Re: [PATCH tip/core/rcu 0/4] Programmatic nestable expedited grace
> > periods
> >
> > On Fri, Feb 20, 2015 at 05:54:09PM +0100, Peter Zijlstra wrote:
> > > On Fri, Fe
On Sat, Feb 21, 2015 at 07:51:34AM -0800, Arjan van de Ven wrote:
> >>
> >>there's a few others as well that I'm chasing down...
> >>.. but the flip side, prior to running ring 3 code, why NOT do fast
> >>expedites?
> >
> >It would be good to have before-and-after measurements of actual
> >boot
On Sat, Feb 21, 2015 at 05:11:30PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 20, 2015 at 10:38:49AM -0800, Paul E. McKenney wrote:
> > On Fri, Feb 20, 2015 at 06:43:59PM +0100, Peter Zijlstra wrote:
> > > On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
> > > > there's a few
On Fri, Feb 20, 2015 at 10:38:49AM -0800, Paul E. McKenney wrote:
> On Fri, Feb 20, 2015 at 06:43:59PM +0100, Peter Zijlstra wrote:
> > On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
> > > there's a few others as well that I'm chasing down...
> > > .. but the flip side, prior to
On Fri, Feb 20, 2015 at 09:45:39AM -0800, Arjan van de Ven wrote:
> On 2/20/2015 9:43 AM, Peter Zijlstra wrote:
> >On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
> >>there's a few others as well that I'm chasing down...
> >>.. but the flip side, prior to running ring 3 code, why
there's a few others as well that I'm chasing down...
.. but the flip side, prior to running ring 3 code, why NOT do fast expedites?
It would be good to have before-and-after measurements of actual
boot time. Are these numbers available?
To show the boot time, I'm using the timestamp of
esnoyers"
> , t...@linutronix.de, rost...@goodmis.org,
> dhowe...@redhat.com, eduma...@google.com,
> dvh...@linux.intel.com, fweis...@gmail.com, o...@redhat.com, "bobby prani"
>
> Sent: Saturday, February 21, 2015 1:04:28 AM
> Subject: Re: [PATCH tip/core/rcu 0/4] Pr
On Sat, Feb 21, 2015 at 07:58:07PM -0800, Josh Triplett wrote:
On Sat, Feb 21, 2015 at 07:51:34AM -0800, Arjan van de Ven wrote:
there's a few others as well that I'm chasing down...
.. but the flip side, prior to running ring 3 code, why NOT do fast
expedites?
It would be good to
On Sat, Feb 21, 2015 at 07:51:34AM -0800, Arjan van de Ven wrote:
there's a few others as well that I'm chasing down...
.. but the flip side, prior to running ring 3 code, why NOT do fast
expedites?
It would be good to have before-and-after measurements of actual
boot time. Are these
On Sat, Feb 21, 2015 at 05:08:52PM +0100, Peter Zijlstra wrote:
On Fri, Feb 20, 2015 at 09:45:39AM -0800, Arjan van de Ven wrote:
On 2/20/2015 9:43 AM, Peter Zijlstra wrote:
On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
there's a few others as well that I'm chasing
Sent: Saturday, February 21, 2015 1:04:28 AM
Subject: Re: [PATCH tip/core/rcu 0/4] Programmatic nestable expedited grace
periods
On Fri, Feb 20, 2015 at 05:54:09PM +0100, Peter Zijlstra wrote:
On Fri, Feb 20, 2015 at 08:37:37AM -0800, Paul E. McKenney wrote:
On Fri, Feb 20, 2015
there's a few others as well that I'm chasing down...
.. but the flip side, prior to running ring 3 code, why NOT do fast expedites?
It would be good to have before-and-after measurements of actual
boot time. Are these numbers available?
To show the boot time, I'm using the timestamp of
On Fri, Feb 20, 2015 at 10:38:49AM -0800, Paul E. McKenney wrote:
On Fri, Feb 20, 2015 at 06:43:59PM +0100, Peter Zijlstra wrote:
On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
there's a few others as well that I'm chasing down...
.. but the flip side, prior to running
/rcu 0/4] Programmatic nestable expedited grace
periods
On Fri, Feb 20, 2015 at 05:54:09PM +0100, Peter Zijlstra wrote:
On Fri, Feb 20, 2015 at 08:37:37AM -0800, Paul E. McKenney wrote:
On Fri, Feb 20, 2015 at 10:11:07AM +0100, Peter Zijlstra wrote:
Does it really make a machine boot much
On Fri, Feb 20, 2015 at 09:45:39AM -0800, Arjan van de Ven wrote:
On 2/20/2015 9:43 AM, Peter Zijlstra wrote:
On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
there's a few others as well that I'm chasing down...
.. but the flip side, prior to running ring 3 code, why NOT do
On Sat, Feb 21, 2015 at 07:51:34AM -0800, Arjan van de Ven wrote:
there's a few others as well that I'm chasing down...
.. but the flip side, prior to running ring 3 code, why NOT do fast
expedites?
It would be good to have before-and-after measurements of actual
boot time. Are these
On Sat, Feb 21, 2015 at 05:11:30PM +0100, Peter Zijlstra wrote:
On Fri, Feb 20, 2015 at 10:38:49AM -0800, Paul E. McKenney wrote:
On Fri, Feb 20, 2015 at 06:43:59PM +0100, Peter Zijlstra wrote:
On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
there's a few others as well
On Fri, Feb 20, 2015 at 05:54:09PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 20, 2015 at 08:37:37AM -0800, Paul E. McKenney wrote:
> > On Fri, Feb 20, 2015 at 10:11:07AM +0100, Peter Zijlstra wrote:
> > > Does it really make a machine boot much faster? Why are people using
> > > synchronous gp
On Fri, Feb 20, 2015 at 10:29:34AM -0800, Arjan van de Ven wrote:
> On 2/20/2015 10:27 AM, Paul E. McKenney wrote:
> >On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
> >>Does it really make a machine boot much faster? Why are people using
> >>synchronous gp primitives if
On Fri, Feb 20, 2015 at 06:43:59PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
> > there's a few others as well that I'm chasing down...
> > .. but the flip side, prior to running ring 3 code, why NOT do fast
> > expedites?
>
> So my
On 2/20/2015 10:27 AM, Paul E. McKenney wrote:
On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
Does it really make a machine boot much faster? Why are people using
synchronous gp primitives if they care about speed? Should we not fix
that instead?
The report I heard was that
On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
> Does it really make a machine boot much faster? Why are people using
> synchronous gp primitives if they care about speed? Should we not fix
> that instead?
> >>>
> >>>The report I heard was that it provided 10-15%
On 2/20/2015 9:43 AM, Peter Zijlstra wrote:
On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
there's a few others as well that I'm chasing down...
.. but the flip side, prior to running ring 3 code, why NOT do fast expedites?
So my objections are twofold:
- I object to
On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
> there's a few others as well that I'm chasing down...
> .. but the flip side, prior to running ring 3 code, why NOT do fast expedites?
So my objections are twofold:
- I object to fast expedites in principle; they spray IPIs
Does it really make a machine boot much faster? Why are people using
synchronous gp primitives if they care about speed? Should we not fix
that instead?
The report I heard was that it provided 10-15% faster boot times.
That's not insignificant; got more details? I think we should really
look
On Fri, Feb 20, 2015 at 05:54:09PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 20, 2015 at 08:37:37AM -0800, Paul E. McKenney wrote:
> > On Fri, Feb 20, 2015 at 10:11:07AM +0100, Peter Zijlstra wrote:
> > > So I though we wanted to get rid / limit the expedited stuff because its
> > > IPI happy,
On Fri, Feb 20, 2015 at 08:37:37AM -0800, Paul E. McKenney wrote:
> On Fri, Feb 20, 2015 at 10:11:07AM +0100, Peter Zijlstra wrote:
> > So I though we wanted to get rid / limit the expedited stuff because its
> > IPI happy, and here its spreading.
>
> Well, at least it no longer IPIs idle CPUs.
On Fri, Feb 20, 2015 at 10:11:07AM +0100, Peter Zijlstra wrote:
> On Thu, Feb 19, 2015 at 09:08:50PM -0800, Paul E. McKenney wrote:
> > Hello!
> >
> > This series, possibly for v3.21, contains changes that allow in-kernel
> > code to specify that all subsequent synchronous grace-period primitives
On Thu, Feb 19, 2015 at 09:08:50PM -0800, Paul E. McKenney wrote:
> Hello!
>
> This series, possibly for v3.21, contains changes that allow in-kernel
> code to specify that all subsequent synchronous grace-period primitives
> (synchronize_rcu() and friends) be expedited. New rcu_expedite_gp()
>
On Thu, Feb 19, 2015 at 09:08:50PM -0800, Paul E. McKenney wrote:
Hello!
This series, possibly for v3.21, contains changes that allow in-kernel
code to specify that all subsequent synchronous grace-period primitives
(synchronize_rcu() and friends) be expedited. New rcu_expedite_gp()
and
On Fri, Feb 20, 2015 at 05:54:09PM +0100, Peter Zijlstra wrote:
On Fri, Feb 20, 2015 at 08:37:37AM -0800, Paul E. McKenney wrote:
On Fri, Feb 20, 2015 at 10:11:07AM +0100, Peter Zijlstra wrote:
Does it really make a machine boot much faster? Why are people using
synchronous gp primitives
On Fri, Feb 20, 2015 at 05:54:09PM +0100, Peter Zijlstra wrote:
On Fri, Feb 20, 2015 at 08:37:37AM -0800, Paul E. McKenney wrote:
On Fri, Feb 20, 2015 at 10:11:07AM +0100, Peter Zijlstra wrote:
So I though we wanted to get rid / limit the expedited stuff because its
IPI happy, and here
On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
there's a few others as well that I'm chasing down...
.. but the flip side, prior to running ring 3 code, why NOT do fast expedites?
So my objections are twofold:
- I object to fast expedites in principle; they spray IPIs
On Fri, Feb 20, 2015 at 10:11:07AM +0100, Peter Zijlstra wrote:
On Thu, Feb 19, 2015 at 09:08:50PM -0800, Paul E. McKenney wrote:
Hello!
This series, possibly for v3.21, contains changes that allow in-kernel
code to specify that all subsequent synchronous grace-period primitives
On Fri, Feb 20, 2015 at 08:37:37AM -0800, Paul E. McKenney wrote:
On Fri, Feb 20, 2015 at 10:11:07AM +0100, Peter Zijlstra wrote:
So I though we wanted to get rid / limit the expedited stuff because its
IPI happy, and here its spreading.
Well, at least it no longer IPIs idle CPUs. ;-)
Does it really make a machine boot much faster? Why are people using
synchronous gp primitives if they care about speed? Should we not fix
that instead?
The report I heard was that it provided 10-15% faster boot times.
That's not insignificant; got more details? I think we should really
look
On 2/20/2015 9:43 AM, Peter Zijlstra wrote:
On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
there's a few others as well that I'm chasing down...
.. but the flip side, prior to running ring 3 code, why NOT do fast expedites?
So my objections are twofold:
- I object to
On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
Does it really make a machine boot much faster? Why are people using
synchronous gp primitives if they care about speed? Should we not fix
that instead?
The report I heard was that it provided 10-15% faster boot times.
On 2/20/2015 10:27 AM, Paul E. McKenney wrote:
On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
Does it really make a machine boot much faster? Why are people using
synchronous gp primitives if they care about speed? Should we not fix
that instead?
The report I heard was that
On Fri, Feb 20, 2015 at 10:29:34AM -0800, Arjan van de Ven wrote:
On 2/20/2015 10:27 AM, Paul E. McKenney wrote:
On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
Does it really make a machine boot much faster? Why are people using
synchronous gp primitives if they care about
On Fri, Feb 20, 2015 at 06:43:59PM +0100, Peter Zijlstra wrote:
On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote:
there's a few others as well that I'm chasing down...
.. but the flip side, prior to running ring 3 code, why NOT do fast
expedites?
So my objections are
Hello!
This series, possibly for v3.21, contains changes that allow in-kernel
code to specify that all subsequent synchronous grace-period primitives
(synchronize_rcu() and friends) be expedited. New rcu_expedite_gp()
and rcu_unexpedite_gp() primitives enable and disable expediting,
and these
Hello!
This series, possibly for v3.21, contains changes that allow in-kernel
code to specify that all subsequent synchronous grace-period primitives
(synchronize_rcu() and friends) be expedited. New rcu_expedite_gp()
and rcu_unexpedite_gp() primitives enable and disable expediting,
and these
50 matches
Mail list logo
