Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1260764 > unrolled thread

Re: [PATCH v3 1/2] cputime: fix invalid gtime in proc

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v3 1/2] cputime: fix invalid gtime in proc Peter Zijlstra <peterz@infradead.org> - 2015-11-02 17:20 +0100
    Re: [PATCH v3 1/2] cputime: fix invalid gtime in proc Frederic Weisbecker <fweisbec@gmail.com> - 2015-11-04 17:20 +0100
      RE: [PATCH v3 1/2] cputime: fix invalid gtime in proc Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> - 2015-11-10 09:50 +0100
        Re: [PATCH v3 1/2] cputime: fix invalid gtime in proc Frederic Weisbecker <fweisbec@gmail.com> - 2015-11-13 16:40 +0100
          Re: [PATCH v3 1/2] cputime: fix invalid gtime in proc Peter Zijlstra <peterz@infradead.org> - 2015-11-13 17:20 +0100
            Re: [PATCH v3 1/2] cputime: fix invalid gtime in proc Frederic Weisbecker <fweisbec@gmail.com> - 2015-11-13 17:20 +0100

#1260764 — Re: [PATCH v3 1/2] cputime: fix invalid gtime in proc

On Fri, Oct 30, 2015 at 12:46:39AM +0000, Hiroshi Shimamoto wrote:
> +++ b/kernel/sched/cputime.c
> @@ -786,6 +786,9 @@ cputime_t task_gtime(struct task_struct *t)
>  	unsigned int seq;
>  	cputime_t gtime;
>  
> +	if (!context_tracking_is_enabled())
> +		return t->gtime;
> +

Yeah, not happy about that.. why do we have to touch context tracking
muck to find vtime state etc.

>  	do {
>  		seq = read_seqbegin(&t->vtime_seqlock);
>  
> -- 
> 1.8.3.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1262411

On Mon, Nov 02, 2015 at 05:13:51PM +0100, Peter Zijlstra wrote:
> On Fri, Oct 30, 2015 at 12:46:39AM +0000, Hiroshi Shimamoto wrote:
> > +++ b/kernel/sched/cputime.c
> > @@ -786,6 +786,9 @@ cputime_t task_gtime(struct task_struct *t)
> >  	unsigned int seq;
> >  	cputime_t gtime;
> >  
> > +	if (!context_tracking_is_enabled())
> > +		return t->gtime;
> > +
> 
> Yeah, not happy about that.. why do we have to touch context tracking
> muck to find vtime state etc.

That's right, this is because it is deemed to be a quick and non invasive fix
to be backported.

Then will come the more invasive but proper fix consisting in having
vtime_accounting_enabled() telling if vtime is running on any CPU and
vtime_accounting_cpu_enabled(). The first will be used for remote readers
(as in this patch) and the second for writers.

Since we are dealing with a regression, it's better to minimize the changes.
AFAICT, the regression got introduced in 2012:

  6a61671bb2f3a1bd12cd17b8fca811a624782632
  ("cputime: Safely read cputime of full dynticks CPUs")

> 
> >  	do {
> >  		seq = read_seqbegin(&t->vtime_seqlock);
> >  
> > -- 
> > 1.8.3.1
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1266331

> Subject: Re: [PATCH v3 1/2] cputime: fix invalid gtime in proc
> 
> On Mon, Nov 02, 2015 at 05:13:51PM +0100, Peter Zijlstra wrote:
> > On Fri, Oct 30, 2015 at 12:46:39AM +0000, Hiroshi Shimamoto wrote:
> > > +++ b/kernel/sched/cputime.c
> > > @@ -786,6 +786,9 @@ cputime_t task_gtime(struct task_struct *t)
> > >  	unsigned int seq;
> > >  	cputime_t gtime;
> > >
> > > +	if (!context_tracking_is_enabled())
> > > +		return t->gtime;
> > > +
> >
> > Yeah, not happy about that.. why do we have to touch context tracking
> > muck to find vtime state etc.
> 
> That's right, this is because it is deemed to be a quick and non invasive fix
> to be backported.
> 
> Then will come the more invasive but proper fix consisting in having
> vtime_accounting_enabled() telling if vtime is running on any CPU and
> vtime_accounting_cpu_enabled(). The first will be used for remote readers
> (as in this patch) and the second for writers.
> 
> Since we are dealing with a regression, it's better to minimize the changes.
> AFAICT, the regression got introduced in 2012:
> 
>   6a61671bb2f3a1bd12cd17b8fca811a624782632
>   ("cputime: Safely read cputime of full dynticks CPUs")

Is this patch going to apply to fix the regression?

thanks,
Hiroshi

> 
> >
> > >  	do {
> > >  		seq = read_seqbegin(&t->vtime_seqlock);
> > >
> > > --
> > > 1.8.3.1
> > >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1269031

On Tue, Nov 10, 2015 at 08:43:17AM +0000, Hiroshi Shimamoto wrote:
> > Subject: Re: [PATCH v3 1/2] cputime: fix invalid gtime in proc
> > 
> > On Mon, Nov 02, 2015 at 05:13:51PM +0100, Peter Zijlstra wrote:
> > > On Fri, Oct 30, 2015 at 12:46:39AM +0000, Hiroshi Shimamoto wrote:
> > > > +++ b/kernel/sched/cputime.c
> > > > @@ -786,6 +786,9 @@ cputime_t task_gtime(struct task_struct *t)
> > > >  	unsigned int seq;
> > > >  	cputime_t gtime;
> > > >
> > > > +	if (!context_tracking_is_enabled())
> > > > +		return t->gtime;
> > > > +
> > >
> > > Yeah, not happy about that.. why do we have to touch context tracking
> > > muck to find vtime state etc.
> > 
> > That's right, this is because it is deemed to be a quick and non invasive fix
> > to be backported.
> > 
> > Then will come the more invasive but proper fix consisting in having
> > vtime_accounting_enabled() telling if vtime is running on any CPU and
> > vtime_accounting_cpu_enabled(). The first will be used for remote readers
> > (as in this patch) and the second for writers.
> > 
> > Since we are dealing with a regression, it's better to minimize the changes.
> > AFAICT, the regression got introduced in 2012:
> > 
> >   6a61671bb2f3a1bd12cd17b8fca811a624782632
> >   ("cputime: Safely read cputime of full dynticks CPUs")
> 
> Is this patch going to apply to fix the regression?

Peter, if you have doubts, I can integrate this change in a larger
series that does a proper cleanup. But this very patch will still need
to be tagged as stable for backport.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1269055

On Fri, Nov 13, 2015 at 04:33:01PM +0100, Frederic Weisbecker wrote:
> Peter, if you have doubts, I can integrate this change in a larger
> series that does a proper cleanup. But this very patch will still need
> to be tagged as stable for backport.

Yeah, I want to see it done proper. I really do not care about backports
much.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1269059

On Fri, Nov 13, 2015 at 05:10:28PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 13, 2015 at 04:33:01PM +0100, Frederic Weisbecker wrote:
> > Peter, if you have doubts, I can integrate this change in a larger
> > series that does a proper cleanup. But this very patch will still need
> > to be tagged as stable for backport.
> 
> Yeah, I want to see it done proper. I really do not care about backports
> much.

Ok, I'll post something soon.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web