[lkml]   [2008]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/3] x86: add cpus_scnprintf function v3
    Mike wrote:
    > Part of the change is readability, but also looking towards the future
    > of 16k/64k/??? # of cpus, the straight mask approach will overflow the
    > PAGE_SIZE buffer provided (though some pathological cases will overflow
    > the range method as well.)

    Bert wrote:
    > Btw, I think you can now push for a deprecation of the 'old' mask
    > attributes, with the justification you have given above. The other
    > possibility is to change sysfs to provide bigger attribute buffers
    > (CCed Greg for this).

    Note what Mike said -- some pathological cases will overflow the range
    (what I call "list") format as well.

    Indeed, the worst case "list" format is worse than the worst case "mask"
    format. Masks take a constant 9 chars per 32 bits, or 9/32 chars/bit.

    Worst case lists involve every other CPU or node (all the even ones, or
    all the odd ones.) For CPUs or Nodes that take five decimal digits
    (10000 to 65535 -- some of these are u16 kernel types internall) this
    amounts to 6 chars every 2 possible values, or 3 chars/bit, which is
    quite a bit more than 9/32 chars/bit.

    For example, the list of odd CPUs from 1 to 65535 takes 191053


    This will overflow any ordinary page size. The corresponding mask
    takes only 18432 characters:


    Deprecating the mask in favor of the list on account of the
    mask not fitting makes little sense to me, because worst case,
    the list is even bigger ;).

    Granted, the above examples consider the extreme case of
    NR_CPUS == 65536 or some such. But, as Mike notes, NR_CPUS
    of 16384 might be needed; and the above quandry still applies
    in that case.

    Hmmm ... there are even more pathological list cases. Take two
    out of every three (drop those congruent to 0 mod 3):


    This requires 254736 characters ;).

    Even for less insane values, of say two out of three CPUs when
    NR_CPUS == 4096, it takes 12912 characters:


    Whereas the mask format for 4096 NR_CPUS takes just 1152 characters.

    On a system with 4K page size, the above two out of three list would
    not actually show as that 12912 character string. With the current
    code, it would show as a 4094 character string, plus the trailing
    newline and nul char, ending with (if I did my math right):


    This is obviously not perfect from an ideal perspective.

    However, I can't see that these pathological cases are enough of a
    practical problem that we should actually spend code addressing them
    at present.

    On the other hand, and my main point of this message, I can't
    see deprecating the mask format files on account of this sort
    of analysis.

    I won't rest till it's the best ...
    Programmer, Linux Scalability
    Paul Jackson <> 1.940.382.4214

     \ /
      Last update: 2008-04-10 14:13    [W:0.023 / U:1.456 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site