lkml.org 
[lkml]   [2008]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Module loading/unloading and "The Stop Machine"
    Tejun Heo wrote:
    > Max Krasnyanskiy wrote:
    >> Tejun Heo wrote:
    >>> Max Krasnyanskiy wrote:
    >>>> Thanks for the info. I guess I missed that from the code. In any case
    >>>> that seems like a pretty heavy refcounting mechanism. In a sense that
    >>>> every time something is loaded or unloaded entire machine freezes,
    >>>> potentially for several milliseconds. Normally it's not a big deal. But
    >>>> once you get more and more CPUs and/or start using realtime apps this
    >>>> becomes a big deal.
    >>> Module loading doesn't involve stop_machine last time I checked. It's a
    >>> big deal when unloading a module but it's actually a very good trade off
    >>> because it makes much hotter path (module_get/put) much cheaper. If
    >>> your application can't stand stop_machine, simply don't unload a module.
    >> static struct module *load_module(void __user *umod,
    >> unsigned long len,
    >> const char __user *uargs)
    >> {
    >> ...
    >>
    >> /* Now sew it into the lists so we can get lockdep and oops
    >> * info during argument parsing. Noone should access us, since
    >> * strong_try_module_get() will fail. */
    >> stop_machine_run(__link_module, mod, NR_CPUS);
    >> ...
    >> }
    >
    > Ah... right. That part doesn't have anything to do with module
    > reference counting as the comment suggests and can probably be removed
    > by updating how kallsyms synchronize against module load/unload.

    That list (updated by __link_module) is accessed in couple of other places. ie outside symbol
    lookup stuff used for kallsyms.

    Max


    \
     
     \ /
      Last update: 2008-02-22 03:19    [W:0.023 / U:30.716 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site