linux-next: manual merge of the tip tree with the cputime tree

linux-next: manual merge of the tip tree with the cputime tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
fs/proc/uptime.c between commit c3e0ef9a298e ("[S390] fix cputime
overflow in uptime_proc_show") from the cputime tree and commit
3292beb340c7 ("sched/accounting: Change cpustat fields to an array") from
the tip tree.

I fixed it up (I think - see below) and can carry the fix as necessary.

Generally, you guys seem to be working a little at cross purposes ...
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/proc/uptime.c
index ab51510,0fb22e4..0000000
--- a/fs/proc/uptime.c
+++ b/fs/proc/uptime.c
@@@ -6,30 -6,25 +6,29 @@@
  #include <linux/time.h>
  #include <linux/kernel_stat.h>
  #include <asm/cputime.h>
  
  static int uptime_proc_show(struct seq_file *m, void *v)
  {
  	struct timespec uptime;
  	struct timespec idle;
- 	cputime64_t idletime;
 +	u64 nsec;
 +	u32 rem;
  	int i;
+ 	u64 idletime = 0;
  
- 	idletime = 0;
  	for_each_possible_cpu(i)
- 		idletime += kstat_cpu(i).cpustat.idle;
+ 		idletime += kcpustat_cpu(i).cpustat[CPUTIME_IDLE];
  
  	do_posix_clock_monotonic_gettime(&uptime);
  	monotonic_to_bootbased(&uptime);
 -	cputime_to_timespec(idletime, &idle);
 +	nsec = cputime64_to_jiffies64(idletime) * TICK_NSEC;
 +	idle.tv_sec = div_u64_rem(nsec, NSEC_PER_SEC, &rem);
 +	idle.tv_nsec = rem;
  	seq_printf(m, "%lu.%02lu %lu.%02lu\n",
  			(unsigned long) uptime.tv_sec,
  			(uptime.tv_nsec / (NSEC_PER_SEC / 100)),
  			(unsigned long) idle.tv_sec,
  			(idle.tv_nsec / (NSEC_PER_SEC / 100)));
  	return 0;
  }
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the tip tree with the cputime tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in
> fs/proc/uptime.c between commit c3e0ef9a298e ("[S390] fix cputime
> overflow in uptime_proc_show") from the cputime tree and commit
> 3292beb340c7 ("sched/accounting: Change cpustat fields to an array") from
> the tip tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary.
> 
> Generally, you guys seem to be working a little at cross purposes ...

Agreed.

Martin, could you please send Peter and me a pull request of the 
current cputime bits merged on top of tip:sched/core? Those bits 
should go upstream via the scheduler tree.

Thanks,

	Ingo

Re: linux-next: manual merge of the tip tree with the cputime tree

[Martin Schwidefsky]

On Mon, 19 Dec 2011 09:08:13 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > Today's linux-next merge of the tip tree got a conflict in
> > fs/proc/uptime.c between commit c3e0ef9a298e ("[S390] fix cputime
> > overflow in uptime_proc_show") from the cputime tree and commit
> > 3292beb340c7 ("sched/accounting: Change cpustat fields to an array") from
> > the tip tree.
> > 
> > I fixed it up (I think - see below) and can carry the fix as necessary.
> > 
> > Generally, you guys seem to be working a little at cross purposes ...
> 
> Agreed.
> 
> Martin, could you please send Peter and me a pull request of the 
> current cputime bits merged on top of tip:sched/core? Those bits 
> should go upstream via the scheduler tree.
> 

All of it including "[S390] cputime: add sparse checking and cleanup" or
just the fix for uptime ?

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: linux-next: manual merge of the tip tree with the cputime tree

[Ingo Molnar]

* Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:

> On Mon, 19 Dec 2011 09:08:13 +0100
> Ingo Molnar <mingo@elte.hu> wrote:
> 
> > 
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > > Hi all,
> > > 
> > > Today's linux-next merge of the tip tree got a conflict in
> > > fs/proc/uptime.c between commit c3e0ef9a298e ("[S390] fix cputime
> > > overflow in uptime_proc_show") from the cputime tree and commit
> > > 3292beb340c7 ("sched/accounting: Change cpustat fields to an array") from
> > > the tip tree.
> > > 
> > > I fixed it up (I think - see below) and can carry the fix as necessary.
> > > 
> > > Generally, you guys seem to be working a little at cross purposes ...
> > 
> > Agreed.
> > 
> > Martin, could you please send Peter and me a pull request of the 
> > current cputime bits merged on top of tip:sched/core? Those bits 
> > should go upstream via the scheduler tree.
> > 
> 
> All of it including "[S390] cputime: add sparse checking and 
> cleanup" or just the fix for uptime ?

I suspect we can take it all if it's all scheduling/time 
related, and add new patches to sched/core to keep it all 
concentrated in a single tree?

Thanks,

	Ingo

Re: linux-next: manual merge of the tip tree with the cputime tree

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> > All of it including "[S390] cputime: add sparse checking and 
> > cleanup" or just the fix for uptime ?
> 
> I suspect we can take it all if it's all scheduling/time 
> related, and add new patches to sched/core to keep it all 
> concentrated in a single tree?

Btw., i'd suggest to keep your commits as-is and merge 
tip:sched/core into your tree - and send the result to me so 
that we can make that the new sched/core.

That way your commits are preserved and the conflicts are 
resolved.

Thanks,

	Ingo

Re: linux-next: manual merge of the tip tree with the cputime tree

[Martin Schwidefsky]

On Mon, 19 Dec 2011 11:35:13 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:
> 
> > On Mon, 19 Dec 2011 09:08:13 +0100
> > Ingo Molnar <mingo@elte.hu> wrote:
> > 
> > > 
> > > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > 
> > > > Hi all,
> > > > 
> > > > Today's linux-next merge of the tip tree got a conflict in
> > > > fs/proc/uptime.c between commit c3e0ef9a298e ("[S390] fix cputime
> > > > overflow in uptime_proc_show") from the cputime tree and commit
> > > > 3292beb340c7 ("sched/accounting: Change cpustat fields to an array") from
> > > > the tip tree.
> > > > 
> > > > I fixed it up (I think - see below) and can carry the fix as necessary.
> > > > 
> > > > Generally, you guys seem to be working a little at cross purposes ...
> > > 
> > > Agreed.
> > > 
> > > Martin, could you please send Peter and me a pull request of the 
> > > current cputime bits merged on top of tip:sched/core? Those bits 
> > > should go upstream via the scheduler tree.
> > > 
> > 
> > All of it including "[S390] cputime: add sparse checking and 
> > cleanup" or just the fix for uptime ?
> 
> I suspect we can take it all if it's all scheduling/time 
> related, and add new patches to sched/core to keep it all 
> concentrated in a single tree?

Ok, will do. Just one question: are you sure that you want the cpustat array
to be u64 instead of cputime64_t? The content of the cpustat array is defined
by the architecture semantics of cputime64_t, for CONFIG_VIRT_CPU_ACCOUNTING=y
this is not a jiffy counter. If the array is u64 we won't get the sparse
checking when reading from cpustat.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: linux-next: manual merge of the tip tree with the cputime tree

[Glauber Costa]

On 12/19/2011 04:31 PM, Martin Schwidefsky wrote:
> On Mon, 19 Dec 2011 11:35:13 +0100
> Ingo Molnar<mingo@elte.hu>  wrote:
>
>>
>> * Martin Schwidefsky<schwidefsky@de.ibm.com>  wrote:
>>
>>> On Mon, 19 Dec 2011 09:08:13 +0100
>>> Ingo Molnar<mingo@elte.hu>  wrote:
>>>
>>>>
>>>> * Stephen Rothwell<sfr@canb.auug.org.au>  wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Today's linux-next merge of the tip tree got a conflict in
>>>>> fs/proc/uptime.c between commit c3e0ef9a298e ("[S390] fix cputime
>>>>> overflow in uptime_proc_show") from the cputime tree and commit
>>>>> 3292beb340c7 ("sched/accounting: Change cpustat fields to an array") from
>>>>> the tip tree.
>>>>>
>>>>> I fixed it up (I think - see below) and can carry the fix as necessary.
>>>>>
>>>>> Generally, you guys seem to be working a little at cross purposes ...
>>>>
>>>> Agreed.
>>>>
>>>> Martin, could you please send Peter and me a pull request of the
>>>> current cputime bits merged on top of tip:sched/core? Those bits
>>>> should go upstream via the scheduler tree.
>>>>
>>>
>>> All of it including "[S390] cputime: add sparse checking and
>>> cleanup" or just the fix for uptime ?
>>
>> I suspect we can take it all if it's all scheduling/time
>> related, and add new patches to sched/core to keep it all
>> concentrated in a single tree?
>
> Ok, will do. Just one question: are you sure that you want the cpustat array
> to be u64 instead of cputime64_t? The content of the cpustat array is defined
> by the architecture semantics of cputime64_t, for CONFIG_VIRT_CPU_ACCOUNTING=y
> this is not a jiffy counter. If the array is u64 we won't get the sparse
> checking when reading from cpustat.
>

 From where I stand, all I care about is for it to be an array. 
Otherwise the cgroup code get quite messy. At the time, and discussing 
this with peterz, it made sense to change it to u64.

If my mind doesn't fail me, the main reason being it cputime64 is u64 
everywhere, and it was just preventing us from doing simple assignments,
like cpustat[idx] += tmp.

But if for whatever reason you want to move it back to cputime64_t, and 
the maintainers agree so,I am fine with that, as long as you don't 
revert to the old scheme of having a struct filled with fields.

Re: linux-next: manual merge of the tip tree with the cputime tree

[Glauber Costa]

On 12/19/2011 04:31 PM, Martin Schwidefsky wrote:
> On Mon, 19 Dec 2011 11:35:13 +0100
> Ingo Molnar<mingo@elte.hu>  wrote:
>
>>
>> * Martin Schwidefsky<schwidefsky@de.ibm.com>  wrote:
>>
>>> On Mon, 19 Dec 2011 09:08:13 +0100
>>> Ingo Molnar<mingo@elte.hu>  wrote:
>>>
>>>>
>>>> * Stephen Rothwell<sfr@canb.auug.org.au>  wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Today's linux-next merge of the tip tree got a conflict in
>>>>> fs/proc/uptime.c between commit c3e0ef9a298e ("[S390] fix cputime
>>>>> overflow in uptime_proc_show") from the cputime tree and commit
>>>>> 3292beb340c7 ("sched/accounting: Change cpustat fields to an array") from
>>>>> the tip tree.
>>>>>
>>>>> I fixed it up (I think - see below) and can carry the fix as necessary.
>>>>>
>>>>> Generally, you guys seem to be working a little at cross purposes ...
>>>>
>>>> Agreed.
>>>>
>>>> Martin, could you please send Peter and me a pull request of the
>>>> current cputime bits merged on top of tip:sched/core? Those bits
>>>> should go upstream via the scheduler tree.
>>>>
>>>
>>> All of it including "[S390] cputime: add sparse checking and
>>> cleanup" or just the fix for uptime ?
>>
>> I suspect we can take it all if it's all scheduling/time
>> related, and add new patches to sched/core to keep it all
>> concentrated in a single tree?
>
> Ok, will do. Just one question: are you sure that you want the cpustat array
> to be u64 instead of cputime64_t? The content of the cpustat array is defined
> by the architecture semantics of cputime64_t, for CONFIG_VIRT_CPU_ACCOUNTING=y
> this is not a jiffy counter. If the array is u64 we won't get the sparse
> checking when reading from cpustat.
>

 From where I stand, all I care about is for it to be an array. 
Otherwise the cgroup code get quite messy. At the time, and discussing 
this with peterz, it made sense to change it to u64.

If my mind doesn't fail me, the main reason being it cputime64 is u64 
everywhere, and it was just preventing us from doing simple assignments,
like cpustat[idx] += tmp.

But if for whatever reason you want to move it back to cputime64_t, and 
the maintainers agree so,I am fine with that, as long as you don't 
revert to the old scheme of having a struct filled with fields.

Re: linux-next: manual merge of the tip tree with the cputime tree

[Peter Zijlstra]

On Mon, 2011-12-19 at 13:31 +0100, Martin Schwidefsky wrote:
> Just one question: are you sure that you want the cpustat array
> to be u64 instead of cputime64_t? The content of the cpustat array is defined
> by the architecture semantics of cputime64_t, for CONFIG_VIRT_CPU_ACCOUNTING=y
> this is not a jiffy counter. If the array is u64 we won't get the sparse
> checking when reading from cpustat. 

So as Glauber said the reason was that we wanted to use simply
operators, and IIRC he wanted to add a few fields that had to be u64.

I'm not sure what the current plans are wrt adding more fields, but with
your work cputime_t should again be a simple type and thus regular math
operators should work again, right?

Glauber, do you still need to add fields?

Re: linux-next: manual merge of the tip tree with the cputime tree

[Martin Schwidefsky]

On Mon, 19 Dec 2011 17:43:23 +0400
Glauber Costa <glommer@parallels.com> wrote:

> On 12/19/2011 04:31 PM, Martin Schwidefsky wrote:
> > On Mon, 19 Dec 2011 11:35:13 +0100
> > Ingo Molnar<mingo@elte.hu>  wrote:
> >
> >>
> >> * Martin Schwidefsky<schwidefsky@de.ibm.com>  wrote:
> >>
> >>> On Mon, 19 Dec 2011 09:08:13 +0100
> >>> Ingo Molnar<mingo@elte.hu>  wrote:
> >>>
> >>>>
> >>>> * Stephen Rothwell<sfr@canb.auug.org.au>  wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> Today's linux-next merge of the tip tree got a conflict in
> >>>>> fs/proc/uptime.c between commit c3e0ef9a298e ("[S390] fix cputime
> >>>>> overflow in uptime_proc_show") from the cputime tree and commit
> >>>>> 3292beb340c7 ("sched/accounting: Change cpustat fields to an array") from
> >>>>> the tip tree.
> >>>>>
> >>>>> I fixed it up (I think - see below) and can carry the fix as necessary.
> >>>>>
> >>>>> Generally, you guys seem to be working a little at cross purposes ...
> >>>>
> >>>> Agreed.
> >>>>
> >>>> Martin, could you please send Peter and me a pull request of the
> >>>> current cputime bits merged on top of tip:sched/core? Those bits
> >>>> should go upstream via the scheduler tree.
> >>>>
> >>>
> >>> All of it including "[S390] cputime: add sparse checking and
> >>> cleanup" or just the fix for uptime ?
> >>
> >> I suspect we can take it all if it's all scheduling/time
> >> related, and add new patches to sched/core to keep it all
> >> concentrated in a single tree?
> >
> > Ok, will do. Just one question: are you sure that you want the cpustat array
> > to be u64 instead of cputime64_t? The content of the cpustat array is defined
> > by the architecture semantics of cputime64_t, for CONFIG_VIRT_CPU_ACCOUNTING=y
> > this is not a jiffy counter. If the array is u64 we won't get the sparse
> > checking when reading from cpustat.
> >
> 
>  From where I stand, all I care about is for it to be an array. 
> Otherwise the cgroup code get quite messy. At the time, and discussing 
> this with peterz, it made sense to change it to u64.
> 
> If my mind doesn't fail me, the main reason being it cputime64 is u64 
> everywhere, and it was just preventing us from doing simple assignments,
> like cpustat[idx] += tmp.
> 
> But if for whatever reason you want to move it back to cputime64_t, and 
> the maintainers agree so,I am fine with that, as long as you don't 
> revert to the old scheme of having a struct filled with fields.

Yes, I would like to have it converted back to cputime64_t. In fact cputime64_t
is a u64 but with a little twist, it has __nocast attached to it. This came out
of the discussion with Peter, he suggested to use sparse to warn about
unannotated conversions between cputime and scalar types. I want to have an
automated way to find these because for architectures with VIRT_CPU_ACCOUNTING
the cputime values are not jiffies.

I have implemented the sparse __nocast approach in the large patch on the
cputime branch. Which now clashes with the conversion of cpustat to an array.
Oh well.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: linux-next: manual merge of the tip tree with the cputime tree

[Martin Schwidefsky]

On Mon, 19 Dec 2011 17:43:23 +0400
Glauber Costa <glommer@parallels.com> wrote:

> On 12/19/2011 04:31 PM, Martin Schwidefsky wrote:
> > On Mon, 19 Dec 2011 11:35:13 +0100
> > Ingo Molnar<mingo@elte.hu>  wrote:
> >
> >>
> >> * Martin Schwidefsky<schwidefsky@de.ibm.com>  wrote:
> >>
> >>> On Mon, 19 Dec 2011 09:08:13 +0100
> >>> Ingo Molnar<mingo@elte.hu>  wrote:
> >>>
> >>>>
> >>>> * Stephen Rothwell<sfr@canb.auug.org.au>  wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> Today's linux-next merge of the tip tree got a conflict in
> >>>>> fs/proc/uptime.c between commit c3e0ef9a298e ("[S390] fix cputime
> >>>>> overflow in uptime_proc_show") from the cputime tree and commit
> >>>>> 3292beb340c7 ("sched/accounting: Change cpustat fields to an array") from
> >>>>> the tip tree.
> >>>>>
> >>>>> I fixed it up (I think - see below) and can carry the fix as necessary.
> >>>>>
> >>>>> Generally, you guys seem to be working a little at cross purposes ...
> >>>>
> >>>> Agreed.
> >>>>
> >>>> Martin, could you please send Peter and me a pull request of the
> >>>> current cputime bits merged on top of tip:sched/core? Those bits
> >>>> should go upstream via the scheduler tree.
> >>>>
> >>>
> >>> All of it including "[S390] cputime: add sparse checking and
> >>> cleanup" or just the fix for uptime ?
> >>
> >> I suspect we can take it all if it's all scheduling/time
> >> related, and add new patches to sched/core to keep it all
> >> concentrated in a single tree?
> >
> > Ok, will do. Just one question: are you sure that you want the cpustat array
> > to be u64 instead of cputime64_t? The content of the cpustat array is defined
> > by the architecture semantics of cputime64_t, for CONFIG_VIRT_CPU_ACCOUNTING=y
> > this is not a jiffy counter. If the array is u64 we won't get the sparse
> > checking when reading from cpustat.
> >
> 
>  From where I stand, all I care about is for it to be an array. 
> Otherwise the cgroup code get quite messy. At the time, and discussing 
> this with peterz, it made sense to change it to u64.
> 
> If my mind doesn't fail me, the main reason being it cputime64 is u64 
> everywhere, and it was just preventing us from doing simple assignments,
> like cpustat[idx] += tmp.
> 
> But if for whatever reason you want to move it back to cputime64_t, and 
> the maintainers agree so,I am fine with that, as long as you don't 
> revert to the old scheme of having a struct filled with fields.

Yes, I would like to have it converted back to cputime64_t. In fact cputime64_t
is a u64 but with a little twist, it has __nocast attached to it. This came out
of the discussion with Peter, he suggested to use sparse to warn about
unannotated conversions between cputime and scalar types. I want to have an
automated way to find these because for architectures with VIRT_CPU_ACCOUNTING
the cputime values are not jiffies.

I have implemented the sparse __nocast approach in the large patch on the
cputime branch. Which now clashes with the conversion of cpustat to an array.
Oh well.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: linux-next: manual merge of the tip tree with the cputime tree

[Martin Schwidefsky]

On Mon, 19 Dec 2011 12:25:47 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > > All of it including "[S390] cputime: add sparse checking and 
> > > cleanup" or just the fix for uptime ?
> > 
> > I suspect we can take it all if it's all scheduling/time 
> > related, and add new patches to sched/core to keep it all 
> > concentrated in a single tree?
> 
> Btw., i'd suggest to keep your commits as-is and merge 
> tip:sched/core into your tree - and send the result to me so 
> that we can make that the new sched/core.
> 
> That way your commits are preserved and the conflicts are 
> resolved.

Just did that and pushed out the result on 

 git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git cputime-tip

Pulling either the original tip sched/core branch or the cputime-tip branch
to an up-to-date repository fails by the way, it gives a conflict in
kernel/sched/fair.c.
And then there is the thing with cpustat being u64. It really should be
cputime64_t. How do you want that resolved, I assume an additional patch
on top?

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: linux-next: manual merge of the tip tree with the cputime tree

[Martin Schwidefsky]

On Mon, 19 Dec 2011 15:08:43 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, 2011-12-19 at 13:31 +0100, Martin Schwidefsky wrote:
> > Just one question: are you sure that you want the cpustat array
> > to be u64 instead of cputime64_t? The content of the cpustat array is defined
> > by the architecture semantics of cputime64_t, for CONFIG_VIRT_CPU_ACCOUNTING=y
> > this is not a jiffy counter. If the array is u64 we won't get the sparse
> > checking when reading from cpustat. 
> 
> So as Glauber said the reason was that we wanted to use simply
> operators, and IIRC he wanted to add a few fields that had to be u64.
> 
> I'm not sure what the current plans are wrt adding more fields, but with
> your work cputime_t should again be a simple type and thus regular math
> operators should work again, right?

Correct.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: linux-next: manual merge of the tip tree with the cputime tree

[Ingo Molnar]

* Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:

> > That way your commits are preserved and the conflicts are 
> > resolved.
> 
> Just did that and pushed out the result on
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git cputime-tip

Hm, this fails spectacularly on 32-bit x86:

/home/mingo/tip/drivers/cpufreq/cpufreq_ondemand.c: In function 'get_cpu_idle_time_jiffy':
/home/mingo/tip/drivers/cpufreq/cpufreq_ondemand.c:137: error: expected ';' before ')' token
/home/mingo/tip/drivers/cpufreq/cpufreq_ondemand.c:137: error: expected statement before ')' token

Thanks,

	Ingo

Re: linux-next: manual merge of the tip tree with the cputime tree

[Martin Schwidefsky]

On Mon, 19 Dec 2011 17:30:09 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:
> 
> > > That way your commits are preserved and the conflicts are 
> > > resolved.
> > 
> > Just did that and pushed out the result on
> > 
> >  git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git cputime-tip
> 
> Hm, this fails spectacularly on 32-bit x86:
> 
> /home/mingo/tip/drivers/cpufreq/cpufreq_ondemand.c: In function 'get_cpu_idle_time_jiffy':
> /home/mingo/tip/drivers/cpufreq/cpufreq_ondemand.c:137: error: expected ';' before ')' token
> /home/mingo/tip/drivers/cpufreq/cpufreq_ondemand.c:137: error: expected statement before ')' token

Arg, sorry. Once more with feeling. I've replaced cputime-tip with a version
that survived "make allmodconfig; make" on x86-32, x86-64, powerpc and s390
(with JUMP_LABEL=n, there is another bug lurking). ia64, the third architecture
with VIRT_CPU_ACCOUNTING=y, does not compile due to a cyclic dependency in
asm-offsets.c vs sched.h. Now it only has to work ..

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: linux-next: manual merge of the tip tree with the cputime tree

[Glauber Costa]

On 12/19/2011 06:08 PM, Peter Zijlstra wrote:
> On Mon, 2011-12-19 at 13:31 +0100, Martin Schwidefsky wrote:
>> Just one question: are you sure that you want the cpustat array
>> to be u64 instead of cputime64_t? The content of the cpustat array is defined
>> by the architecture semantics of cputime64_t, for CONFIG_VIRT_CPU_ACCOUNTING=y
>> this is not a jiffy counter. If the array is u64 we won't get the sparse
>> checking when reading from cpustat.
>
> So as Glauber said the reason was that we wanted to use simply
> operators, and IIRC he wanted to add a few fields that had to be u64.
>
> I'm not sure what the current plans are wrt adding more fields, but with
> your work cputime_t should again be a simple type and thus regular math
> operators should work again, right?
>
> Glauber, do you still need to add fields?

Due to the current state of discussions of cpu vs cpuacct, I think the 
final state of this is quite unclear. However, I think Martin's work is
a quite worthwhile piece for us to have. So last case we can add extra 
fields in a different array and tell them apart by the index, etc. It 
shouldn't be expensive at all.

Re: linux-next: manual merge of the tip tree with the cputime tree

[Glauber Costa]

On 12/19/2011 06:08 PM, Peter Zijlstra wrote:
> On Mon, 2011-12-19 at 13:31 +0100, Martin Schwidefsky wrote:
>> Just one question: are you sure that you want the cpustat array
>> to be u64 instead of cputime64_t? The content of the cpustat array is defined
>> by the architecture semantics of cputime64_t, for CONFIG_VIRT_CPU_ACCOUNTING=y
>> this is not a jiffy counter. If the array is u64 we won't get the sparse
>> checking when reading from cpustat.
>
> So as Glauber said the reason was that we wanted to use simply
> operators, and IIRC he wanted to add a few fields that had to be u64.
>
> I'm not sure what the current plans are wrt adding more fields, but with
> your work cputime_t should again be a simple type and thus regular math
> operators should work again, right?
>
> Glauber, do you still need to add fields?

Due to the current state of discussions of cpu vs cpuacct, I think the 
final state of this is quite unclear. However, I think Martin's work is
a quite worthwhile piece for us to have. So last case we can add extra 
fields in a different array and tell them apart by the index, etc. It 
shouldn't be expensive at all.

Re: linux-next: manual merge of the tip tree with the cputime tree

[Ingo Molnar]

* Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:

> [...] I've replaced cputime-tip with a version that survived 
> "make allmodconfig; make" on x86-32, x86-64, powerpc and s390 
> (with JUMP_LABEL=n, there is another bug lurking). ia64, the 
> third architecture with VIRT_CPU_ACCOUNTING=y, does not 
> compile due to a cyclic dependency in asm-offsets.c vs 
> sched.h. Now it only has to work ..

It's looking good so far here. Pulled, thanks Martin!

Thanks,

	Ingo

Re: linux-next: manual merge of the tip tree with the cputime tree

[Martin Schwidefsky]

On Wed, 7 Dec 2011 09:35:09 -0200
Glauber Costa <glommer@parallels.com> wrote:

> On 12/07/2011 02:09 AM, Stephen Rothwell wrote:
> > + 	index = (TASK_NICE(p)>  0) ? CPUTIME_NICE : CPUTIME_USER;
> > +
> >    	/* Add user time to cpustat. */
> > - 	if (TASK_NICE(p)>  0)
> > - 		cpustat->nice += (__force cputime64_t) cputime;
> > - 	else
> > - 		cpustat->user += (__force cputime64_t) cputime;
> >   -	task_group_account_field(p, index, cputime);
> > ++	task_group_account_field(p, index, (__force cputime64_t) cputime);
> 
> 
> I doubt __force cputime64_t is necessary. After these patches, those 
> fields are all u64.

You need the __force keyword whenever a conversion between a cputime[64]_t
and a plain scalar type is done. The cputime[64]_t types are defined with
__nocast so that sparse can find bugs in the usage of cputime.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: linux-next: manual merge of the tip tree with the cputime tree

[Martin Schwidefsky]

On Wed, 7 Dec 2011 09:35:09 -0200
Glauber Costa <glommer@parallels.com> wrote:

> On 12/07/2011 02:09 AM, Stephen Rothwell wrote:
> > + 	index = (TASK_NICE(p)>  0) ? CPUTIME_NICE : CPUTIME_USER;
> > +
> >    	/* Add user time to cpustat. */
> > - 	if (TASK_NICE(p)>  0)
> > - 		cpustat->nice += (__force cputime64_t) cputime;
> > - 	else
> > - 		cpustat->user += (__force cputime64_t) cputime;
> >   -	task_group_account_field(p, index, cputime);
> > ++	task_group_account_field(p, index, (__force cputime64_t) cputime);
> 
> 
> I doubt __force cputime64_t is necessary. After these patches, those 
> fields are all u64.

You need the __force keyword whenever a conversion between a cputime[64]_t
and a plain scalar type is done. The cputime[64]_t types are defined with
__nocast so that sparse can find bugs in the usage of cputime.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: linux-next: manual merge of the tip tree with the cputime tree

[Glauber Costa]

On 12/07/2011 02:09 AM, Stephen Rothwell wrote:
> + 	index = (TASK_NICE(p)>  0) ? CPUTIME_NICE : CPUTIME_USER;
> +
>    	/* Add user time to cpustat. */
> - 	if (TASK_NICE(p)>  0)
> - 		cpustat->nice += (__force cputime64_t) cputime;
> - 	else
> - 		cpustat->user += (__force cputime64_t) cputime;
>   -	task_group_account_field(p, index, cputime);
> ++	task_group_account_field(p, index, (__force cputime64_t) cputime);


I doubt __force cputime64_t is necessary. After these patches, those 
fields are all u64.

Re: linux-next: manual merge of the tip tree with the cputime tree

[Glauber Costa]

On 12/07/2011 02:09 AM, Stephen Rothwell wrote:
> + 	index = (TASK_NICE(p)>  0) ? CPUTIME_NICE : CPUTIME_USER;
> +
>    	/* Add user time to cpustat. */
> - 	if (TASK_NICE(p)>  0)
> - 		cpustat->nice += (__force cputime64_t) cputime;
> - 	else
> - 		cpustat->user += (__force cputime64_t) cputime;
>   -	task_group_account_field(p, index, cputime);
> ++	task_group_account_field(p, index, (__force cputime64_t) cputime);


I doubt __force cputime64_t is necessary. After these patches, those 
fields are all u64.

linux-next: manual merge of the tip tree with the cputime tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the tip tree got conflicts in
kernel/sched/core.c, fs/proc/uptime.c, fs/proc/stat.c,
drivers/cpufreq/cpufreq_conservative.c,
drivers/cpufreq/cpufreq_ondemand.c and drivers/macintosh/rack-meter.c
between commit c5927fe412bf ("[S390] cputime: add sparse checking and
cleanup") from the cputime tree and commit 3292beb340c7
("sched/accounting: Change cpustat fields to an array") from the tip tree.

I fixed it up (I hope - see below) and can carry the fix as necessary.  (I
used the tip version of fs/proc/uptime.c, fs/proc/stat.c and
drivers/macintosh/rack-meter.c).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/sched/core.c
index 18cad44,3c5b21e..0000000
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@@ -2166,7 -935,7 +935,7 @@@ static int irqtime_account_hi_update(vo
  
  	local_irq_save(flags);
  	latest_ns = this_cpu_read(cpu_hardirq_time);
- 	if (nsecs_to_cputime64(latest_ns) > cpustat->irq)
 -	if (cputime64_gt(nsecs_to_cputime64(latest_ns), cpustat[CPUTIME_IRQ]))
++	if (nsecs_to_cputime64(latest_ns) > cpustat[CPUTIME_IRQ])
  		ret = 1;
  	local_irq_restore(flags);
  	return ret;
@@@ -2181,7 -950,7 +950,7 @@@ static int irqtime_account_si_update(vo
  
  	local_irq_save(flags);
  	latest_ns = this_cpu_read(cpu_softirq_time);
- 	if (nsecs_to_cputime64(latest_ns) > cpustat->softirq)
 -	if (cputime64_gt(nsecs_to_cputime64(latest_ns), cpustat[CPUTIME_SOFTIRQ]))
++	if (nsecs_to_cputime64(latest_ns) > cpustat[CPUTIME_SOFTIRQ])
  		ret = 1;
  	local_irq_restore(flags);
  	return ret;
@@@ -3867,20 -2633,18 +2633,18 @@@ static inline void task_group_account_f
  void account_user_time(struct task_struct *p, cputime_t cputime,
  		       cputime_t cputime_scaled)
  {
- 	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
+ 	int index;
  
  	/* Add user time to process. */
 -	p->utime = cputime_add(p->utime, cputime);
 -	p->utimescaled = cputime_add(p->utimescaled, cputime_scaled);
 +	p->utime += cputime;
 +	p->utimescaled += cputime_scaled;
  	account_group_user_time(p, cputime);
  
+ 	index = (TASK_NICE(p) > 0) ? CPUTIME_NICE : CPUTIME_USER;
+ 
  	/* Add user time to cpustat. */
- 	if (TASK_NICE(p) > 0)
- 		cpustat->nice += (__force cputime64_t) cputime;
- 	else
- 		cpustat->user += (__force cputime64_t) cputime;
 -	task_group_account_field(p, index, cputime);
++	task_group_account_field(p, index, (__force cputime64_t) cputime);
  
- 	cpuacct_update_stats(p, CPUACCT_STAT_USER, cputime);
  	/* Account for user time used */
  	acct_update_integrals(p);
  }
@@@ -3894,21 -2658,24 +2658,21 @@@
  static void account_guest_time(struct task_struct *p, cputime_t cputime,
  			       cputime_t cputime_scaled)
  {
- 	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
 -	u64 tmp;
+ 	u64 *cpustat = kcpustat_this_cpu->cpustat;
  
 -	tmp = cputime_to_cputime64(cputime);
 -
  	/* Add guest time to process. */
 -	p->utime = cputime_add(p->utime, cputime);
 -	p->utimescaled = cputime_add(p->utimescaled, cputime_scaled);
 +	p->utime += cputime;
 +	p->utimescaled += cputime_scaled;
  	account_group_user_time(p, cputime);
 -	p->gtime = cputime_add(p->gtime, cputime);
 +	p->gtime += cputime;
  
  	/* Add guest time to cpustat. */
  	if (TASK_NICE(p) > 0) {
- 		cpustat->nice += (__force cputime64_t) cputime;
- 		cpustat->guest_nice += (__force cputime64_t) cputime;
 -		cpustat[CPUTIME_NICE] += tmp;
 -		cpustat[CPUTIME_GUEST_NICE] += tmp;
++		cpustat[CPUTIME_NICE] += (__force cputime64_t) cputime;
++		cpustat[CPUTIME_GUEST_NICE] += (__force cputime64_t) cputime;
  	} else {
- 		cpustat->user += (__force cputime64_t) cputime;
- 		cpustat->guest += (__force cputime64_t) cputime;
 -		cpustat[CPUTIME_USER] += tmp;
 -		cpustat[CPUTIME_GUEST] += tmp;
++		cpustat[CPUTIME_USER] += (__force cputime64_t) cputime;
++		cpustat[CPUTIME_GUEST] += (__force cputime64_t) cputime;
  	}
  }
  
@@@ -3921,16 -2688,15 +2685,15 @@@
   */
  static inline
  void __account_system_time(struct task_struct *p, cputime_t cputime,
- 			cputime_t cputime_scaled, cputime64_t *target_cputime64)
+ 			cputime_t cputime_scaled, int index)
  {
  	/* Add system time to process. */
 -	p->stime = cputime_add(p->stime, cputime);
 -	p->stimescaled = cputime_add(p->stimescaled, cputime_scaled);
 +	p->stime += cputime;
 +	p->stimescaled += cputime_scaled;
  	account_group_system_time(p, cputime);
  
  	/* Add system time to cpustat. */
- 	*target_cputime64 += (__force cputime64_t) cputime;
- 	cpuacct_update_stats(p, CPUACCT_STAT_SYSTEM, cputime);
 -	task_group_account_field(p, index, cputime);
++	task_group_account_field(p, index, (__force cputime64_t) cputime);
  
  	/* Account for system time used */
  	acct_update_integrals(p);
@@@ -3970,9 -2735,10 +2732,9 @@@ void account_system_time(struct task_st
   */
  void account_steal_time(cputime_t cputime)
  {
- 	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
+ 	u64 *cpustat = kcpustat_this_cpu->cpustat;
 -	u64 cputime64 = cputime_to_cputime64(cputime);
  
- 	cpustat->steal += (__force cputime64_t) cputime;
 -	cpustat[CPUTIME_STEAL] += cputime64;
++	cpustat[CPUTIME_STEAL] += (__force cputime64_t) cputime;
  }
  
  /*
@@@ -3981,13 -2747,14 +2743,13 @@@
   */
  void account_idle_time(cputime_t cputime)
  {
- 	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
+ 	u64 *cpustat = kcpustat_this_cpu->cpustat;
  	struct rq *rq = this_rq();
  
  	if (atomic_read(&rq->nr_iowait) > 0)
- 		cpustat->iowait += (__force cputime64_t) cputime;
 -		cpustat[CPUTIME_IOWAIT] += cputime64;
++		cpustat[CPUTIME_IOWAIT] += (__force cputime64_t) cputime;
  	else
- 		cpustat->idle += (__force cputime64_t) cputime;
 -		cpustat[CPUTIME_IDLE] += cputime64;
++		cpustat[CPUTIME_IDLE] += (__force cputime64_t) cputime;
  }
  
  static __always_inline bool steal_account_process_tick(void)
@@@ -4037,15 -2804,16 +2799,15 @@@ static void irqtime_account_process_tic
  						struct rq *rq)
  {
  	cputime_t one_jiffy_scaled = cputime_to_scaled(cputime_one_jiffy);
- 	struct cpu_usage_stat *cpustat = &kstat_this_cpu.cpustat;
 -	u64 tmp = cputime_to_cputime64(cputime_one_jiffy);
+ 	u64 *cpustat = kcpustat_this_cpu->cpustat;
  
  	if (steal_account_process_tick())
  		return;
  
  	if (irqtime_account_hi_update()) {
- 		cpustat->irq += (__force cputime64_t) cputime_one_jiffy;
 -		cpustat[CPUTIME_IRQ] += tmp;
++		cpustat[CPUTIME_IRQ] += (__force cputime64_t) cputime_one_jiffy;
  	} else if (irqtime_account_si_update()) {
- 		cpustat->softirq += (__force cputime64_t) cputime_one_jiffy;
 -		cpustat[CPUTIME_SOFTIRQ] += tmp;
++		cpustat[CPUTIME_SOFTIRQ] += (__force cputime64_t) cputime_one_jiffy;
  	} else if (this_cpu_ksoftirqd() == p) {
  		/*
  		 * ksoftirqd time do not get accounted in cpu_softirq_time.
diff --cc drivers/cpufreq/cpufreq_conservative.c
index 7f31a03,118bff7..0000000
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@@ -95,26 -95,26 +95,26 @@@ static struct dbs_tuners 
  	.freq_step = 5,
  };
  
- static inline cputime64_t get_cpu_idle_time_jiffy(unsigned int cpu,
- 							cputime64_t *wall)
+ static inline u64 get_cpu_idle_time_jiffy(unsigned int cpu, u64 *wall)
  {
- 	cputime64_t idle_time;
+ 	u64 idle_time;
  	cputime64_t cur_wall_time;
- 	cputime64_t busy_time;
+ 	u64 busy_time;
  
  	cur_wall_time = jiffies64_to_cputime64(get_jiffies_64());
- 	busy_time  = kstat_cpu(cpu).cpustat.user;
- 	busy_time += kstat_cpu(cpu).cpustat.system;
- 	busy_time += kstat_cpu(cpu).cpustat.irq;
- 	busy_time += kstat_cpu(cpu).cpustat.softirq;
- 	busy_time += kstat_cpu(cpu).cpustat.steal;
- 	busy_time += kstat_cpu(cpu).cpustat.nice;
+ 	busy_time = kcpustat_cpu(cpu).cpustat[CPUTIME_USER] +
+ 		    kcpustat_cpu(cpu).cpustat[CPUTIME_SYSTEM];
+ 
+ 	busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_IRQ];
+ 	busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_SOFTIRQ];
+ 	busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_STEAL];
+ 	busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_NICE];
  
 -	idle_time = cputime64_sub(cur_wall_time, busy_time);
 +	idle_time = cur_wall_time - busy_time;
  	if (wall)
- 		*wall = (cputime64_t)jiffies_to_usecs(cur_wall_time);
+ 		*wall = jiffies_to_usecs(cur_wall_time);
  
- 	return (cputime64_t)jiffies_to_usecs(idle_time);
+ 	return jiffies_to_usecs(idle_time);
  }
  
  static inline cputime64_t get_cpu_idle_time(unsigned int cpu, cputime64_t *wall)
diff --cc drivers/cpufreq/cpufreq_ondemand.c
index 07cffe2,f3d327c..0000000
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@@ -119,26 -119,26 +119,26 @@@ static struct dbs_tuners 
  	.powersave_bias = 0,
  };
  
- static inline cputime64_t get_cpu_idle_time_jiffy(unsigned int cpu,
- 							cputime64_t *wall)
+ static inline u64 get_cpu_idle_time_jiffy(unsigned int cpu, u64 *wall)
  {
- 	cputime64_t idle_time;
+ 	u64 idle_time;
  	cputime64_t cur_wall_time;
- 	cputime64_t busy_time;
+ 	u64 busy_time;
  
  	cur_wall_time = jiffies64_to_cputime64(get_jiffies_64());
- 	busy_time  = kstat_cpu(cpu).cpustat.user;
- 	busy_time += kstat_cpu(cpu).cpustat.system;
- 	busy_time += kstat_cpu(cpu).cpustat.irq;
- 	busy_time += kstat_cpu(cpu).cpustat.softirq;
- 	busy_time += kstat_cpu(cpu).cpustat.steal;
- 	busy_time += kstat_cpu(cpu).cpustat.nice;
+ 	busy_time = kcpustat_cpu(cpu).cpustat[CPUTIME_USER] +
+ 		    kcpustat_cpu(cpu).cpustat[CPUTIME_SYSTEM];
+ 
+ 	busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_IRQ];
+ 	busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_SOFTIRQ];
+ 	busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_STEAL];
+ 	busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_NICE];
  
 -	idle_time = cputime64_sub(cur_wall_time, busy_time);
 +	idle_time = cur_wall_time - busy_time;
  	if (wall)
- 		*wall = (cputime64_t)jiffies_to_usecs(cur_wall_time);
+ 		*wall = jiffies_to_usecs(cur_wall_time);
  
- 	return (cputime64_t)jiffies_to_usecs(idle_time);
+ 	return jiffies_to_usecs(idle_time);
  }
  
  static inline cputime64_t get_cpu_idle_time(unsigned int cpu, cputime64_t *wall)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the tip tree with the cputime tree

[Michal Hocko]

On Tue 25-10-11 18:40:02, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in
> include/asm-generic/cputime.h between commit f6116715d1ba ("[S390]
> cputime: add sparse checking and cleanup") from the cputime tree and
> commit ef0e0f5ed9bd ("cputime: Clean up cputime_to_usecs and
> usecs_to_cputime macros") from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

This one looks good as well.

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc include/asm-generic/cputime.h
> index 77202e2,62ce682..0000000
> --- a/include/asm-generic/cputime.h
> +++ b/include/asm-generic/cputime.h
> @@@ -23,10 -38,8 +23,10 @@@ typedef u64 __nocast cputime64_t
>   /*
>    * Convert cputime to microseconds and back.
>    */
>  -#define cputime_to_usecs(__ct)		jiffies_to_usecs(__ct)
>  -#define usecs_to_cputime(__msecs)	usecs_to_jiffies(__msecs)
>  +#define cputime_to_usecs(__ct)		\
> - 	jiffies_to_usecs(cputime_to_jiffies(__ct));
> ++	jiffies_to_usecs(cputime_to_jiffies(__ct))
>  +#define usecs_to_cputime(__msecs)	\
> - 	jiffies_to_cputime(usecs_to_jiffies(__msecs));
> ++	jiffies_to_cputime(usecs_to_jiffies(__msecs))
>   
>   /*
>    * Convert cputime to seconds and back.



-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: linux-next: manual merge of the tip tree with the cputime tree

[Michal Hocko]

On Tue 25-10-11 18:35:18, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in fs/proc/stat.c
> between commit f6116715d1ba ("[S390] cputime: add sparse checking and
> cleanup") from the cputime tree and commit a25cac5198d4 ("proc: Consider
> NO_HZ when printing idle and iowait times") from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

Looks good.

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc fs/proc/stat.c
> index 566cd04,42b274d..0000000
> --- a/fs/proc/stat.c
> +++ b/fs/proc/stat.c
> @@@ -21,6 -22,35 +22,34 @@@
>   #define arch_idle_time(cpu) 0
>   #endif
>   
> + static cputime64_t get_idle_time(int cpu)
> + {
> + 	u64 idle_time = get_cpu_idle_time_us(cpu, NULL);
> + 	cputime64_t idle;
> + 
> + 	if (idle_time == -1ULL) {
> + 		/* !NO_HZ so we can rely on cpustat.idle */
>  -		idle = kstat_cpu(cpu).cpustat.idle;
>  -		idle = cputime64_add(idle, arch_idle_time(cpu));
> ++		idle = kstat_cpu(cpu).cpustat.idle + arch_idle_time(cpu);
> + 	} else
> + 		idle = usecs_to_cputime(idle_time);
> + 
> + 	return idle;
> + }
> + 
> + static cputime64_t get_iowait_time(int cpu)
> + {
> + 	u64 iowait_time = get_cpu_iowait_time_us(cpu, NULL);
> + 	cputime64_t iowait;
> + 
> + 	if (iowait_time == -1ULL)
> + 		/* !NO_HZ so we can rely on cpustat.iowait */
> + 		iowait = kstat_cpu(cpu).cpustat.iowait;
> + 	else
> + 		iowait = usecs_to_cputime(iowait_time);
> + 
> + 	return iowait;
> + }
> + 
>   static int show_stat(struct seq_file *p, void *v)
>   {
>   	int i, j;
> @@@ -39,16 -69,17 +68,16 @@@
>   	jif = boottime.tv_sec;
>   
>   	for_each_possible_cpu(i) {
>  -		user = cputime64_add(user, kstat_cpu(i).cpustat.user);
>  -		nice = cputime64_add(nice, kstat_cpu(i).cpustat.nice);
>  -		system = cputime64_add(system, kstat_cpu(i).cpustat.system);
>  -		idle = cputime64_add(idle, get_idle_time(i));
>  -		iowait = cputime64_add(iowait, get_iowait_time(i));
>  -		irq = cputime64_add(irq, kstat_cpu(i).cpustat.irq);
>  -		softirq = cputime64_add(softirq, kstat_cpu(i).cpustat.softirq);
>  -		steal = cputime64_add(steal, kstat_cpu(i).cpustat.steal);
>  -		guest = cputime64_add(guest, kstat_cpu(i).cpustat.guest);
>  -		guest_nice = cputime64_add(guest_nice,
>  -			kstat_cpu(i).cpustat.guest_nice);
>  +		user += kstat_cpu(i).cpustat.user;
>  +		nice += kstat_cpu(i).cpustat.nice;
>  +		system += kstat_cpu(i).cpustat.system;
> - 		idle += kstat_cpu(i).cpustat.idle + arch_idle_time(i);
> - 		iowait += kstat_cpu(i).cpustat.iowait;
> ++		idle += get_idle_time(i);
> ++		iowait +=  get_iowait_time(i);
>  +		irq += kstat_cpu(i).cpustat.irq;
>  +		softirq += kstat_cpu(i).cpustat.softirq;
>  +		steal += kstat_cpu(i).cpustat.steal;
>  +		guest += kstat_cpu(i).cpustat.guest;
>  +		guest_nice += kstat_cpu(i).cpustat.guest_nice;
>   		sum += kstat_cpu_irqs_sum(i);
>   		sum += arch_irq_stat_cpu(i);
>   



-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

linux-next: manual merge of the tip tree with the cputime tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
kernel/sched_stats.h between commit f6116715d1ba ("[S390] cputime: add
sparse checking and cleanup") from the cputime tree and commit
ee30a7b2fc07 ("locking, sched: Annotate thread_group_cputimer as raw")
from the tip tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/sched_stats.h
index a455e62,87f9e36..0000000
--- a/kernel/sched_stats.h
+++ b/kernel/sched_stats.h
@@@ -282,9 -282,10 +282,9 @@@ static inline void account_group_user_t
  	if (!cputimer->running)
  		return;
  
- 	spin_lock(&cputimer->lock);
+ 	raw_spin_lock(&cputimer->lock);
 -	cputimer->cputime.utime =
 -		cputime_add(cputimer->cputime.utime, cputime);
 +	cputimer->cputime.utime += cputime;
- 	spin_unlock(&cputimer->lock);
+ 	raw_spin_unlock(&cputimer->lock);
  }
  
  /**
@@@ -305,9 -306,10 +305,9 @@@ static inline void account_group_system
  	if (!cputimer->running)
  		return;
  
- 	spin_lock(&cputimer->lock);
+ 	raw_spin_lock(&cputimer->lock);
 -	cputimer->cputime.stime =
 -		cputime_add(cputimer->cputime.stime, cputime);
 +	cputimer->cputime.stime += cputime;
- 	spin_unlock(&cputimer->lock);
+ 	raw_spin_unlock(&cputimer->lock);
  }
  
  /**

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the tip tree with the cputime tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
include/asm-generic/cputime.h between commit f6116715d1ba ("[S390]
cputime: add sparse checking and cleanup") from the cputime tree and
commit ef0e0f5ed9bd ("cputime: Clean up cputime_to_usecs and
usecs_to_cputime macros") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/asm-generic/cputime.h
index 77202e2,62ce682..0000000
--- a/include/asm-generic/cputime.h
+++ b/include/asm-generic/cputime.h
@@@ -23,10 -38,8 +23,10 @@@ typedef u64 __nocast cputime64_t
  /*
   * Convert cputime to microseconds and back.
   */
 -#define cputime_to_usecs(__ct)		jiffies_to_usecs(__ct)
 -#define usecs_to_cputime(__msecs)	usecs_to_jiffies(__msecs)
 +#define cputime_to_usecs(__ct)		\
- 	jiffies_to_usecs(cputime_to_jiffies(__ct));
++	jiffies_to_usecs(cputime_to_jiffies(__ct))
 +#define usecs_to_cputime(__msecs)	\
- 	jiffies_to_cputime(usecs_to_jiffies(__msecs));
++	jiffies_to_cputime(usecs_to_jiffies(__msecs))
  
  /*
   * Convert cputime to seconds and back.

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the tip tree with the cputime tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in fs/proc/stat.c
between commit f6116715d1ba ("[S390] cputime: add sparse checking and
cleanup") from the cputime tree and commit a25cac5198d4 ("proc: Consider
NO_HZ when printing idle and iowait times") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/proc/stat.c
index 566cd04,42b274d..0000000
--- a/fs/proc/stat.c
+++ b/fs/proc/stat.c
@@@ -21,6 -22,35 +22,34 @@@
  #define arch_idle_time(cpu) 0
  #endif
  
+ static cputime64_t get_idle_time(int cpu)
+ {
+ 	u64 idle_time = get_cpu_idle_time_us(cpu, NULL);
+ 	cputime64_t idle;
+ 
+ 	if (idle_time == -1ULL) {
+ 		/* !NO_HZ so we can rely on cpustat.idle */
 -		idle = kstat_cpu(cpu).cpustat.idle;
 -		idle = cputime64_add(idle, arch_idle_time(cpu));
++		idle = kstat_cpu(cpu).cpustat.idle + arch_idle_time(cpu);
+ 	} else
+ 		idle = usecs_to_cputime(idle_time);
+ 
+ 	return idle;
+ }
+ 
+ static cputime64_t get_iowait_time(int cpu)
+ {
+ 	u64 iowait_time = get_cpu_iowait_time_us(cpu, NULL);
+ 	cputime64_t iowait;
+ 
+ 	if (iowait_time == -1ULL)
+ 		/* !NO_HZ so we can rely on cpustat.iowait */
+ 		iowait = kstat_cpu(cpu).cpustat.iowait;
+ 	else
+ 		iowait = usecs_to_cputime(iowait_time);
+ 
+ 	return iowait;
+ }
+ 
  static int show_stat(struct seq_file *p, void *v)
  {
  	int i, j;
@@@ -39,16 -69,17 +68,16 @@@
  	jif = boottime.tv_sec;
  
  	for_each_possible_cpu(i) {
 -		user = cputime64_add(user, kstat_cpu(i).cpustat.user);
 -		nice = cputime64_add(nice, kstat_cpu(i).cpustat.nice);
 -		system = cputime64_add(system, kstat_cpu(i).cpustat.system);
 -		idle = cputime64_add(idle, get_idle_time(i));
 -		iowait = cputime64_add(iowait, get_iowait_time(i));
 -		irq = cputime64_add(irq, kstat_cpu(i).cpustat.irq);
 -		softirq = cputime64_add(softirq, kstat_cpu(i).cpustat.softirq);
 -		steal = cputime64_add(steal, kstat_cpu(i).cpustat.steal);
 -		guest = cputime64_add(guest, kstat_cpu(i).cpustat.guest);
 -		guest_nice = cputime64_add(guest_nice,
 -			kstat_cpu(i).cpustat.guest_nice);
 +		user += kstat_cpu(i).cpustat.user;
 +		nice += kstat_cpu(i).cpustat.nice;
 +		system += kstat_cpu(i).cpustat.system;
- 		idle += kstat_cpu(i).cpustat.idle + arch_idle_time(i);
- 		iowait += kstat_cpu(i).cpustat.iowait;
++		idle += get_idle_time(i);
++		iowait +=  get_iowait_time(i);
 +		irq += kstat_cpu(i).cpustat.irq;
 +		softirq += kstat_cpu(i).cpustat.softirq;
 +		steal += kstat_cpu(i).cpustat.steal;
 +		guest += kstat_cpu(i).cpustat.guest;
 +		guest_nice += kstat_cpu(i).cpustat.guest_nice;
  		sum += kstat_cpu_irqs_sum(i);
  		sum += arch_irq_stat_cpu(i);
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]