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

From: Glauber Costa <glommer@parallels.com>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	<linux-next@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: manual merge of the tip tree with the cputime tree
Date: Mon, 19 Dec 2011 17:43:23 +0400	[thread overview]
Message-ID: <4EEF3F7B.9080405@parallels.com> (raw)
In-Reply-To: <20111219133151.4d14af80@de.ibm.com>

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.