lkml.org 
[lkml]   [2004]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectbitmap, cpumask_arith (was: 2.6.6-rc1-mm1)
    Ok ... lets see here.

    This message is in reply to 4 messages from Bill Irwin, dated:
    Sat, 17 Apr 2004 19:26:38 -0700
    Sun, 18 Apr 2004 23:29:14 -0700
    Sun, 18 Apr 2004 23:49:43 -0700
    Mon, 19 Apr 2004 00:06:43 -0700


    > I'm having enough trouble remembering what Paul Jackson's take on things

    My take was that in my work-in-progress bitmap/cpumask patches, I have:

    1) Slightly strengthened the constraints (post-conditions) on
    bitmap ops to not set tail bits so long as none were set on
    input. This mostly means that the complement operator zeros
    out the tail. The operators that return scalar (weight,
    for example) or boolean (empty and full, for example) are
    still careful to avoid depending on the state of the tail.

    This changes Bill Irwin's "don't care" rule into a "don't
    care, but don't pollute further" rule.

    2) Removed cpumask_arith entirely, along with 30 odd other files,
    to be replaced by a single cpumask.h set of macros, layered
    rather thinly on top of bitmap/bitop.


    > The important aspect of these is that they're pertinent to small SMP
    > systems, ...

    I tried making this point before, but failed to communicate. Let me try
    again. So far as I know, there is no instance in current Linux kernel
    code using this cpumask facility that is affected (currently broken) by
    the cpumask_arith bugs addressed by Bill's patch. Do you know of any
    breakage in other _current_ code caused by these cpumask_arith bugs,
    Bill?

    As a consequence of my seeing nothing else yet overtly busted by this,
    it was, and remains, my recommendation to Bill to hold off on these
    patches. Little sense in correcting the semantics of a piece of code
    that I expected to remove shortly anyway, if nothing else cared for now.

    However, I realize that Bill takes considerable pride in his work, and
    would like to see this fixed. It's not worth a big fuss, either way,
    so far as I can tell.


    > Paul, please remove akpm from the cc: list

    I have removed akpm from this reply.


    > the users of small SMP systems who are affected by the bug(s) you
    > reported.

    I am unaware that any user of any small SMP (or other) system
    is affected by these bugs.


    > If you could review and/or send approval or the like that would be
    > very helpful ...

    If we can agree on the actual state of affairs, then I will readily
    agree to such to Andrew, and let him decide on the merits and
    appropriate timing of this patch.

    From what I know now, this would mean telling Andrew, of Bill's patch:

    This patch fixes some bugs in the small SMP system (2 to 32 CPU) flavor
    of cpumasks. From what we know now, these bugs aren't breaking any
    other existing code, but they are an accident waiting to happen.
    If Paul Jackson's bitmap/cpumask rework is adapted in the future,
    then this code being patched would be replaced anyway. But for now,
    these fixes are a definite improvement.

    If this does not seem like a correct statement of affairs, lets hash
    that out. Then when we agree, you should present your patch to him on
    the lkml again, and I will gladly chime in with my endorsement.

    Unless, of course, you change your mind and decide to hold off on this
    patch, to which I would even more readily agree <grin>.


    > I have taken issue only where I believe you need to acquire arch
    > maintainer feedback.

    And I have agreed that this is an excellent request. I was out on
    vacation last week, and hesitated to start the arch maintainer discussion
    the week before, knowing that I would be on vacation, and not wanting to
    start something I would not be around to follow through on.

    But I am back now, and expect later this week to begin that discussion,
    as you have recommended.

    --
    I won't rest till it's the best ...
    Programmer, Linux Scalability
    Paul Jackson <pj@sgi.com> 1.650.933.1373
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:02    [W:3.364 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site