Re: Module loading/unloading and "The Stop Machine"

[Max Krasnyanskiy <maxk@qualcomm.com>]

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);
      ...
}

I actually rarely unload modules. The way I notice the problem in first place is when 
things started hanging when tun driver was autoloaded or when fs automounts triggered 
some auto loading.
These days it's kind hard to have a semi-general purpose machine without module loading :).

Max