[PATCH 1/2 -tip] sched: Clean unused fields from struct rq

[PATCH 1/2 -tip] sched: Clean unused fields from struct rq

[Luis Henriques]

Since they are used on in statistics and are always set to zero, the following
frields from struct rq have been removed: yld_exp_empty, yld_act_empty and
yld_both_empty.

Signed-off-by: Luis Henriques <henrix@sapo.pt>
---
 kernel/sched.c       |    3 ---
 kernel/sched_debug.c |    3 ---
 kernel/sched_stats.h |    5 ++---
 3 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index 4000304..289eac2 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -646,9 +646,6 @@ struct rq {
 	/* could above be rq->cfs_rq.exec_clock + rq->rt_rq.rt_runtime ? */
 
 	/* sys_sched_yield() stats */
-	unsigned int yld_exp_empty;
-	unsigned int yld_act_empty;
-	unsigned int yld_both_empty;
 	unsigned int yld_count;
 
 	/* schedule() stats */
diff --git a/kernel/sched_debug.c b/kernel/sched_debug.c
index 2b1260f..1f16606 100644
--- a/kernel/sched_debug.c
+++ b/kernel/sched_debug.c
@@ -287,9 +287,6 @@ static void print_cpu(struct seq_file *m, int cpu)
 #ifdef CONFIG_SCHEDSTATS
 #define P(n) SEQ_printf(m, "  .%-30s: %d\n", #n, rq->n);
 
-	P(yld_exp_empty);
-	P(yld_act_empty);
-	P(yld_both_empty);
 	P(yld_count);
 
 	P(sched_switch);
diff --git a/kernel/sched_stats.h b/kernel/sched_stats.h
index a8f93dd..2e7287a 100644
--- a/kernel/sched_stats.h
+++ b/kernel/sched_stats.h
@@ -26,9 +26,8 @@ static int show_schedstat(struct seq_file *seq, void *v)
 
 		/* runqueue-specific stats */
 		seq_printf(seq,
-		    "cpu%d %u %u %u %u %u %u %u %u %u %llu %llu %lu",
-		    cpu, rq->yld_both_empty,
-		    rq->yld_act_empty, rq->yld_exp_empty, rq->yld_count,
+		    "cpu%d %u %u %u %u %u %u %llu %llu %lu",
+		    cpu, rq->yld_count,
 		    rq->sched_switch, rq->sched_count, rq->sched_goidle,
 		    rq->ttwu_count, rq->ttwu_local,
 		    rq->rq_cpu_time,
-- 
1.6.2


-- 
Luis Henriques

Re: [PATCH 1/2 -tip] sched: Clean unused fields from struct rq

[Peter Zijlstra]

On Wed, 2009-03-18 at 00:03 +0000, Luis Henriques wrote:
> Since they are used on in statistics and are always set to zero, the following
> frields from struct rq have been removed: yld_exp_empty, yld_act_empty and
> yld_both_empty.
> 
> Signed-off-by: Luis Henriques <henrix@sapo.pt>
> ---

> +++ b/kernel/sched_stats.h
> @@ -26,9 +26,8 @@ static int show_schedstat(struct seq_file *seq, void *v)
>  
>  		/* runqueue-specific stats */
>  		seq_printf(seq,
> -		    "cpu%d %u %u %u %u %u %u %u %u %u %llu %llu %lu",
> -		    cpu, rq->yld_both_empty,
> -		    rq->yld_act_empty, rq->yld_exp_empty, rq->yld_count,
> +		    "cpu%d %u %u %u %u %u %u %llu %llu %lu",
> +		    cpu, rq->yld_count,
>  		    rq->sched_switch, rq->sched_count, rq->sched_goidle,
>  		    rq->ttwu_count, rq->ttwu_local,
>  		    rq->rq_cpu_time,

I think this bit is ABI, so you either have to bump the version number
or emit 0s, iirc gregory touched some of that last -- or at least wrote
userspace for it..

Re: [PATCH 1/2 -tip] sched: Clean unused fields from struct rq

[Luis Henriques]

On Wed, Mar 18, 2009 at 01:09:29AM +0100, Peter Zijlstra wrote:
> On Wed, 2009-03-18 at 00:03 +0000, Luis Henriques wrote:
> > Since they are used on in statistics and are always set to zero, the following
> > frields from struct rq have been removed: yld_exp_empty, yld_act_empty and
> > yld_both_empty.
> > 
> > Signed-off-by: Luis Henriques <henrix@sapo.pt>
> > ---
> 
> > +++ b/kernel/sched_stats.h
> > @@ -26,9 +26,8 @@ static int show_schedstat(struct seq_file *seq, void *v)
> >  
> >  		/* runqueue-specific stats */
> >  		seq_printf(seq,
> > -		    "cpu%d %u %u %u %u %u %u %u %u %u %llu %llu %lu",
> > -		    cpu, rq->yld_both_empty,
> > -		    rq->yld_act_empty, rq->yld_exp_empty, rq->yld_count,
> > +		    "cpu%d %u %u %u %u %u %u %llu %llu %lu",
> > +		    cpu, rq->yld_count,
> >  		    rq->sched_switch, rq->sched_count, rq->sched_goidle,
> >  		    rq->ttwu_count, rq->ttwu_local,
> >  		    rq->rq_cpu_time,
> 
> I think this bit is ABI, so you either have to bump the version number
> or emit 0s, iirc gregory touched some of that last -- or at least wrote
> userspace for it..

Hmm... you're right.  I should have though about that.  Anyway, what is the
the best approach here?

I know that changes in ABI shall not break anything, but just increasing the
version number will really solve the issue?  Will userspace care for this?
On the other hand, just writting 0s does not sound interesting either...

-- 
Luis Henriques

Re: [PATCH 1/2 -tip] sched: Clean unused fields from struct rq

[Gregory Haskins]

[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

Luis Henriques wrote:
> On Wed, Mar 18, 2009 at 01:09:29AM +0100, Peter Zijlstra wrote:
>   
>> On Wed, 2009-03-18 at 00:03 +0000, Luis Henriques wrote:
>>     
>>> Since they are used on in statistics and are always set to zero, the following
>>> frields from struct rq have been removed: yld_exp_empty, yld_act_empty and
>>> yld_both_empty.
>>>
>>> Signed-off-by: Luis Henriques <henrix@sapo.pt>
>>> ---
>>>       
>>> +++ b/kernel/sched_stats.h
>>> @@ -26,9 +26,8 @@ static int show_schedstat(struct seq_file *seq, void *v)
>>>  
>>>  		/* runqueue-specific stats */
>>>  		seq_printf(seq,
>>> -		    "cpu%d %u %u %u %u %u %u %u %u %u %llu %llu %lu",
>>> -		    cpu, rq->yld_both_empty,
>>> -		    rq->yld_act_empty, rq->yld_exp_empty, rq->yld_count,
>>> +		    "cpu%d %u %u %u %u %u %u %llu %llu %lu",
>>> +		    cpu, rq->yld_count,
>>>  		    rq->sched_switch, rq->sched_count, rq->sched_goidle,
>>>  		    rq->ttwu_count, rq->ttwu_local,
>>>  		    rq->rq_cpu_time,
>>>       
>> I think this bit is ABI, so you either have to bump the version number
>> or emit 0s, iirc gregory touched some of that last -- or at least wrote
>> userspace for it..
>>     
>
> Hmm... you're right.  I should have though about that.  Anyway, what is the
> the best approach here?
>
> I know that changes in ABI shall not break anything, but just increasing the
> version number will really solve the issue?  Will userspace care for this?
> On the other hand, just writting 0s does not sound interesting either...
>
>   
Hi Luis,
  My app does check the version number, so bumping it is probably the
best solution.   Be sure to keep me in the loop about whether this patch
gets merged and I will be sure to update it to handle the new version.

Regards,
-Greg






[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [PATCH 1/2 -tip] sched: Clean unused fields from struct rq

[Peter Zijlstra]

On Tue, 2009-03-17 at 21:33 -0400, Gregory Haskins wrote:

> > I know that changes in ABI shall not break anything, but just increasing the
> > version number will really solve the issue?  Will userspace care for this?
> > On the other hand, just writting 0s does not sound interesting either...
> >
> >   
> Hi Luis,
>   My app does check the version number, so bumping it is probably the
> best solution.   Be sure to keep me in the loop about whether this patch
> gets merged and I will be sure to update it to handle the new version.

Ah, right, you did say something :-)

/me says to himself, read more mail before answering..

Re: [PATCH 1/2 -tip] sched: Clean unused fields from struct rq

[Luis Henriques]

On Tue, Mar 17, 2009 at 09:33:19PM -0400, Gregory Haskins wrote:
> >> I think this bit is ABI, so you either have to bump the version number
> >> or emit 0s, iirc gregory touched some of that last -- or at least wrote
> >> userspace for it..
> >>     
> >
> > Hmm... you're right.  I should have though about that.  Anyway, what is the
> > the best approach here?
> >
> > I know that changes in ABI shall not break anything, but just increasing the
> > version number will really solve the issue?  Will userspace care for this?
> > On the other hand, just writting 0s does not sound interesting either...
> >
> >   
> Hi Luis,
>   My app does check the version number, so bumping it is probably the
> best solution.   Be sure to keep me in the loop about whether this patch
> gets merged and I will be sure to update it to handle the new version.

Hi Greg,

(sorry for the _huge_ delay for replying, but my timeslice for lkml is quite
small...)

I'll quickly prepare another patch that also modifies the version and repost it.
Maybe you can then give me more feedback on it.

Thanks for comments.
-- 
Luis Henriques

Re: [PATCH 1/2 -tip] sched: Clean unused fields from struct rq

[Peter Zijlstra]

On Wed, 2009-03-18 at 00:23 +0000, Luis Henriques wrote:
> On Wed, Mar 18, 2009 at 01:09:29AM +0100, Peter Zijlstra wrote:
> > On Wed, 2009-03-18 at 00:03 +0000, Luis Henriques wrote:
> > > Since they are used on in statistics and are always set to zero, the following
> > > frields from struct rq have been removed: yld_exp_empty, yld_act_empty and
> > > yld_both_empty.
> > > 
> > > Signed-off-by: Luis Henriques <henrix@sapo.pt>
> > > ---
> > 
> > > +++ b/kernel/sched_stats.h
> > > @@ -26,9 +26,8 @@ static int show_schedstat(struct seq_file *seq, void *v)
> > >  
> > >  		/* runqueue-specific stats */
> > >  		seq_printf(seq,
> > > -		    "cpu%d %u %u %u %u %u %u %u %u %u %llu %llu %lu",
> > > -		    cpu, rq->yld_both_empty,
> > > -		    rq->yld_act_empty, rq->yld_exp_empty, rq->yld_count,
> > > +		    "cpu%d %u %u %u %u %u %u %llu %llu %lu",
> > > +		    cpu, rq->yld_count,
> > >  		    rq->sched_switch, rq->sched_count, rq->sched_goidle,
> > >  		    rq->ttwu_count, rq->ttwu_local,
> > >  		    rq->rq_cpu_time,
> > 
> > I think this bit is ABI, so you either have to bump the version number
> > or emit 0s, iirc gregory touched some of that last -- or at least wrote
> > userspace for it..
> 
> Hmm... you're right.  I should have though about that.  Anyway, what is the
> the best approach here?
> 
> I know that changes in ABI shall not break anything, but just increasing the
> version number will really solve the issue?  Will userspace care for this?
> On the other hand, just writting 0s does not sound interesting either...

I really don't know, Greg, do you as a schedstat user have an opinion?

There is a 3rd option though, you could figure out what they were
supposed to count and see if that can be mapped on the current code.

Not at all sure that's worth the trouble though -- but for completeness
sake, I felt the need to mention it :-)