lkml.org 
[lkml]   [1999]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: spin_unlock optimization
    Date
    On Thu, 30 Dec 1999 22:21:03 +0000, 
    Steve Dodd <dirk@loth.demon.co.uk> wrote:
    >On Thu, Dec 30, 1999 at 04:06:04AM +0100, Oliver Henning wrote:
    >> well, not necessarily. If you would modify the spin_unlock asm sequence at
    >> boot time, there would be no performance loss. But self-modifying code is
    >> not very desirable, so...
    >
    >Erm, spin_unlock is inlined isn't it? So that won't work unless you want to
    >grep for the code sequence all over the kernel and modules; also, the binary
    >module people would be forced to brutally murder you :-)

    It is technically possible to automate this, using the same trick as
    copy_from_user. spin_unlock generates worst case code and stores the
    start and end of the code in yet another ELF section. Kernel boot code
    decides which version to use, runs the data in the new ELF section and
    patches the code before starting the second processor. insmod does the
    same thing. Cost is extra storage in zImage and modules, the extra
    section would be discarded after loading so it does not bloat the
    running kernel. Binary modules (yuck) compiled with the old
    spin_unlock would not have the optimized code but they would still
    work.

    Whether this is a desirable thing to do is another question ;).


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:0.021 / U:1.972 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site