Messages in this thread | | | Date | Thu, 21 Feb 2008 18:16:40 -0800 | From | Max Krasnyanskiy <> | Subject | Re: 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
| |