lkml.org 
[lkml]   [2011]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: linux-next: manual merge of the tip tree with the cputime tree
    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.



    \
     
     \ /
      Last update: 2011-12-19 15:21    [W:0.029 / U:31.040 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site