On Mon, 19 Dec 2011 17:43:23 +0400
Glauber Costa <glommer@xxxxxxxxxxxxx> wrote:
> 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.
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.
--
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
