On 12/19/2011 04:31 PM, Martin Schwidefsky wrote:
On Mon, 19 Dec 2011 11:35:13 +0100
Ingo Molnar<mingo@xxxxxxx> wrote:
* Martin Schwidefsky<schwidefsky@xxxxxxxxxx> wrote:
On Mon, 19 Dec 2011 09:08:13 +0100
Ingo Molnar<mingo@xxxxxxx> wrote:
* Stephen Rothwell<sfr@xxxxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
