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
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 fir
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 ti
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 chas
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 ti
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 other
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 the
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 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 pri
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 t
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
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% fast
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 fast
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 acro
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 a
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
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()
> a
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 may
25 matches
Mail list logo
