[lkml]   [2007]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 1/8] Immediate Values - Global Modules List and Module Mutex
    On Thu, 2007-09-13 at 17:21 -0400, Mathieu Desnoyers wrote:
    > * Rusty Russell ( wrote:
    > > Sure, but why is that the caller's problem? immediate_set() isn't
    > > fastpath, so why not make it do an "if (early_boot)" internally?
    > I see two reasons:
    > 1 - early_boot, or anything that looks like this, does not exist
    > currently (and the following reason might show why).
    > 2 - If we use this, we cannot declare the early code with __init, so it
    > will have to stay there forever insteaf of being removable once boot is
    > over.
    > Therefore, I think it's better to stick to an immediate_set_early
    > version.

    My problem is that I don't know when to use immediate_set_early! You
    say "early boot": what does that mean? Is it arch-specific? And why is
    it my problem anyway?

    Since arch_immediate_update_early() is a memcpy, I don't really buy the
    bloat argument (it has some silly-looking optimization, but that should
    be removed anyway). I'd really rather see arch_immediate_update()
    examine an internal flag and do the memcpy if it's too early for the
    full algorithm. That's the only place which really knows, after all.
    You may need some external hook to update that internal "too early"
    flag, of course.

    Alternatively, if you called it "immediate_init" then the semantics
    change slightly, but are more obvious (ie. only use this when the value
    isn't being accessed yet). But it can't be __init then anyway.

    On an unrelated note, did you consider simply IPI-ing and doing the
    substitution with all CPUs stopped? If you only updated the immediate
    references to this particular var, it should be fast enough not to upset
    the RT guys, even.

    > > I was thinking that we might find useful specific cases before we get
    > > GCC support, which archs can override with tricky asm if they wish.
    > >
    > The first useful case is the Linux Kernel Markers, which really needs a
    > completely boolean if: active or inactive. That would be a good test
    > case to get gcc support.

    Well, you can do that in asm without gcc support. It's a little nasty:
    since gcc will know nothing about the function call, it can't have side
    effects which are visible in this function, and you'll have to save and
    restore *all* regs if you decide to do the function call. But it's
    possible (a 5-byte nop gets changed to a call, the call does the pushes
    and sets the args regs, calls the function, then pops everything and


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-09-14 01:19    [W:0.021 / U:1.588 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site