On 05/06/2015 08:59 PM, Frederic Weisbecker wrote:
> On Mon, May 04, 2015 at 04:53:16PM -0400, Rik van Riel wrote:
>> Ingo's idea is to simply have cpu 0 check the current task
>> on all other CPUs, see whether that task is running in system
>> mode, user mode, guest mode, irq mode, etc and update
On Mon, May 04, 2015 at 04:53:16PM -0400, Rik van Riel wrote:
> On 05/04/2015 04:38 PM, Paul E. McKenney wrote:
> > On Mon, May 04, 2015 at 04:13:50PM -0400, Rik van Riel wrote:
> >> On 05/04/2015 04:02 PM, Paul E. McKenney wrote:
>
> >>> Hmmm... But didn't earlier performance measurements show t
On Wed, 2015-05-06 at 08:52 +0200, Mike Galbraith wrote:
> On Tue, 2015-05-05 at 23:06 -0700, Paul E. McKenney wrote:
>
> > > 1 * stat() on isolated cpu
> > >
> > > NO_HZ_FULL offinactive housekeepernohz_full
> > > real0m14.266s 0m14.367s0m20.427s 0m27.921
On Tue, 2015-05-05 at 23:06 -0700, Paul E. McKenney wrote:
> > 1 * stat() on isolated cpu
> >
> > NO_HZ_FULL offinactive housekeepernohz_full
> > real0m14.266s 0m14.367s0m20.427s 0m27.921s
> > user0m1.756s 0m1.553s 0m1.976s 0m10.447s
>
On Wed, May 06, 2015 at 05:44:54AM +0200, Mike Galbraith wrote:
> On Wed, 2015-05-06 at 03:49 +0200, Mike Galbraith wrote:
> > On Mon, 2015-05-04 at 22:54 -0700, Paul E. McKenney wrote:
> >
> > > You have RCU_FAST_NO_HZ=y, correct? Could you please try measuring with
> > > RCU_FAST_NO_HZ=n?
> >
On Tue, May 05, 2015 at 05:09:23PM -0400, Rik van Riel wrote:
> On 05/05/2015 02:35 PM, Paul E. McKenney wrote:
> > On Tue, May 05, 2015 at 03:00:26PM +0200, Peter Zijlstra wrote:
> >> On Tue, May 05, 2015 at 05:34:46AM -0700, Paul E. McKenney wrote:
> >>> On Tue, May 05, 2015 at 12:53:46PM +0200,
On Wed, 2015-05-06 at 03:49 +0200, Mike Galbraith wrote:
> On Mon, 2015-05-04 at 22:54 -0700, Paul E. McKenney wrote:
>
> > You have RCU_FAST_NO_HZ=y, correct? Could you please try measuring with
> > RCU_FAST_NO_HZ=n?
>
> FWIW, the syscall numbers I posted were RCU_FAST_NO_HZ=n. (I didn't
> pro
On Mon, 2015-05-04 at 22:54 -0700, Paul E. McKenney wrote:
> You have RCU_FAST_NO_HZ=y, correct? Could you please try measuring with
> RCU_FAST_NO_HZ=n?
FWIW, the syscall numbers I posted were RCU_FAST_NO_HZ=n. (I didn't
profile to see where costs lie though)
-Mike
--
To unsubscribe f
On 05/05/2015 02:35 PM, Paul E. McKenney wrote:
> On Tue, May 05, 2015 at 03:00:26PM +0200, Peter Zijlstra wrote:
>> On Tue, May 05, 2015 at 05:34:46AM -0700, Paul E. McKenney wrote:
>>> On Tue, May 05, 2015 at 12:53:46PM +0200, Peter Zijlstra wrote:
On Mon, May 04, 2015 at 12:39:23PM -0700, P
On Tue, May 05, 2015 at 03:00:26PM +0200, Peter Zijlstra wrote:
> On Tue, May 05, 2015 at 05:34:46AM -0700, Paul E. McKenney wrote:
> > On Tue, May 05, 2015 at 12:53:46PM +0200, Peter Zijlstra wrote:
> > > On Mon, May 04, 2015 at 12:39:23PM -0700, Paul E. McKenney wrote:
> > > > But in non-preempti
On Tue, May 05, 2015 at 05:34:46AM -0700, Paul E. McKenney wrote:
> On Tue, May 05, 2015 at 12:53:46PM +0200, Peter Zijlstra wrote:
> > On Mon, May 04, 2015 at 12:39:23PM -0700, Paul E. McKenney wrote:
> > > But in non-preemptible RCU, we have PREEMPT=n, so there is no preempt
> > > counter in prod
On Tue, May 05, 2015 at 12:53:46PM +0200, Peter Zijlstra wrote:
> On Mon, May 04, 2015 at 12:39:23PM -0700, Paul E. McKenney wrote:
> > But in non-preemptible RCU, we have PREEMPT=n, so there is no preempt
> > counter in production kernels. Even if there was, we have to sample this
> > on other CP
On Tue, May 05, 2015 at 12:51:02PM +0200, Peter Zijlstra wrote:
> On Tue, May 05, 2015 at 12:48:34PM +0200, Peter Zijlstra wrote:
> > On Mon, May 04, 2015 at 03:00:44PM -0400, Rik van Riel wrote:
> > In case of the non-preemptible RCU, we could easily also
> > > increase current->rcu_read_lock_nes
On Mon, May 04, 2015 at 12:39:23PM -0700, Paul E. McKenney wrote:
> But in non-preemptible RCU, we have PREEMPT=n, so there is no preempt
> counter in production kernels. Even if there was, we have to sample this
> on other CPUs, so the overhead of preempt_disable() and preempt_enable()
> would be
On Tue, May 05, 2015 at 12:48:34PM +0200, Peter Zijlstra wrote:
> On Mon, May 04, 2015 at 03:00:44PM -0400, Rik van Riel wrote:
> In case of the non-preemptible RCU, we could easily also
> > increase current->rcu_read_lock_nesting at the same time
> > we increase the preempt counter, and use that
On Mon, May 04, 2015 at 03:00:44PM -0400, Rik van Riel wrote:
In case of the non-preemptible RCU, we could easily also
> increase current->rcu_read_lock_nesting at the same time
> we increase the preempt counter, and use that as the
> indicator to test whether the cpu is in an extended
> rcu quies
On Mon, May 04, 2015 at 04:53:16PM -0400, Rik van Riel wrote:
> On 05/04/2015 04:38 PM, Paul E. McKenney wrote:
> > On Mon, May 04, 2015 at 04:13:50PM -0400, Rik van Riel wrote:
> >> On 05/04/2015 04:02 PM, Paul E. McKenney wrote:
>
> >>> Hmmm... But didn't earlier performance measurements show t
On 05/04/2015 04:38 PM, Paul E. McKenney wrote:
> On Mon, May 04, 2015 at 04:13:50PM -0400, Rik van Riel wrote:
>> On 05/04/2015 04:02 PM, Paul E. McKenney wrote:
>>> Hmmm... But didn't earlier performance measurements show that the bulk of
>>> the overhead was the delta-time computations rather
On Mon, May 04, 2015 at 03:59:02PM -0400, Rik van Riel wrote:
> On 05/04/2015 03:39 PM, Paul E. McKenney wrote:
> > On Mon, May 04, 2015 at 03:00:44PM -0400, Rik van Riel wrote:
>
> >> In case of the non-preemptible RCU, we could easily also
> >> increase current->rcu_read_lock_nesting at the same
On Mon, May 04, 2015 at 04:13:50PM -0400, Rik van Riel wrote:
> On 05/04/2015 04:02 PM, Paul E. McKenney wrote:
> > On Mon, May 04, 2015 at 03:39:25PM -0400, Rik van Riel wrote:
> >> On 05/04/2015 02:39 PM, Paul E. McKenney wrote:
> >>> On Mon, May 04, 2015 at 11:59:05AM -0400, Rik van Riel wrote:
On 05/04/2015 04:02 PM, Paul E. McKenney wrote:
> On Mon, May 04, 2015 at 03:39:25PM -0400, Rik van Riel wrote:
>> On 05/04/2015 02:39 PM, Paul E. McKenney wrote:
>>> On Mon, May 04, 2015 at 11:59:05AM -0400, Rik van Riel wrote:
>>
In fact, would we be able to simply use tsk->rcu_read_lock_nes
On Mon, May 04, 2015 at 03:39:25PM -0400, Rik van Riel wrote:
> On 05/04/2015 02:39 PM, Paul E. McKenney wrote:
> > On Mon, May 04, 2015 at 11:59:05AM -0400, Rik van Riel wrote:
>
> >> In fact, would we be able to simply use tsk->rcu_read_lock_nesting
> >> as an indicator of whether or not we shou
On 05/04/2015 03:39 PM, Paul E. McKenney wrote:
> On Mon, May 04, 2015 at 03:00:44PM -0400, Rik van Riel wrote:
>> In case of the non-preemptible RCU, we could easily also
>> increase current->rcu_read_lock_nesting at the same time
>> we increase the preempt counter, and use that as the
>> indicat
On 05/04/2015 02:39 PM, Paul E. McKenney wrote:
> On Mon, May 04, 2015 at 11:59:05AM -0400, Rik van Riel wrote:
>> In fact, would we be able to simply use tsk->rcu_read_lock_nesting
>> as an indicator of whether or not we should bother waiting on that
>> task or CPU when doing synchronize_rcu?
>
On Mon, May 04, 2015 at 03:00:44PM -0400, Rik van Riel wrote:
> On 05/04/2015 11:59 AM, Rik van Riel wrote:
>
> > However, currently the RCU code seems to use a much more
> > complex counting scheme, with a different increment for
> > kernel/task use, and irq use.
> >
> > This counter seems to be
On 05/04/2015 11:59 AM, Rik van Riel wrote:
> However, currently the RCU code seems to use a much more
> complex counting scheme, with a different increment for
> kernel/task use, and irq use.
>
> This counter seems to be modeled on the task preempt_counter,
> where we do care about whether we ar
On Mon, May 04, 2015 at 11:59:05AM -0400, Rik van Riel wrote:
> On 05/04/2015 05:26 AM, Paolo Bonzini wrote:
>
> > Isn't this racy?
> >
> > synchronize_rcu CPU nohz CPU
> > -
> > set fl
On 05/04/2015 05:26 AM, Paolo Bonzini wrote:
> Isn't this racy?
>
> synchronize_rcu CPU nohz CPU
> -
> set flag = 0
> read flag = 0
> r
28 matches
Mail list logo
