Messages in this thread | | | Date | Fri, 22 Feb 2008 10:59:23 +0900 | From | Tejun Heo <> | Subject | Re: Module loading/unloading and "The Stop Machine" |
| |
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.
> 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 :).
Yeap, agreed.
-- tejun
| |