Re: Re: [RFC PATCH 5/5] module: Remove stop_machine from module unloading

2014-10-21 Thread Rusty Russell
Masami Hiramatsu writes: >>> +/* >>> + * MODULE_REF_BASE must be 1, since we use atomic_inc_not_zero() for >>> + * recovering refcnt (see try_release_module_ref() ). >>> + */ >>> +#define MODULE_REF_BASE1 >> >> True, but we could use atomic_add_unless() instead, and make this >> completely

Re: Re: [RFC PATCH 5/5] module: Remove stop_machine from module unloading

2014-10-21 Thread Masami Hiramatsu
(2014/10/13 13:40), Rusty Russell wrote: >> +/* >> + * MODULE_REF_BASE must be 1, since we use atomic_inc_not_zero() for >> + * recovering refcnt (see try_release_module_ref() ). >> + */ >> +#define MODULE_REF_BASE 1 > > True, but we could use atomic_add_unless() instead, and make this >

Re: Re: [RFC PATCH 5/5] module: Remove stop_machine from module unloading

2014-10-21 Thread Masami Hiramatsu
(2014/10/13 13:40), Rusty Russell wrote: > Masami Hiramatsu writes: >> Remove stop_machine from module unloading by replacing module_ref >> with atomic_t. Note that this can cause a performance regression >> on big-SMP machine by direct memory access. For those machines, >> you can lockdwon all

Re: Re: [RFC PATCH 5/5] module: Remove stop_machine from module unloading

2014-10-21 Thread Masami Hiramatsu
(2014/10/13 13:40), Rusty Russell wrote: Masami Hiramatsu masami.hiramatsu...@hitachi.com writes: Remove stop_machine from module unloading by replacing module_ref with atomic_t. Note that this can cause a performance regression on big-SMP machine by direct memory access. For those machines,

Re: Re: [RFC PATCH 5/5] module: Remove stop_machine from module unloading

2014-10-21 Thread Masami Hiramatsu
(2014/10/13 13:40), Rusty Russell wrote: +/* + * MODULE_REF_BASE must be 1, since we use atomic_inc_not_zero() for + * recovering refcnt (see try_release_module_ref() ). + */ +#define MODULE_REF_BASE 1 True, but we could use atomic_add_unless() instead, and make this completely

Re: Re: [RFC PATCH 5/5] module: Remove stop_machine from module unloading

2014-10-21 Thread Rusty Russell
Masami Hiramatsu masami.hiramatsu...@hitachi.com writes: +/* + * MODULE_REF_BASE must be 1, since we use atomic_inc_not_zero() for + * recovering refcnt (see try_release_module_ref() ). + */ +#define MODULE_REF_BASE1 True, but we could use atomic_add_unless() instead, and make this

Re: [RFC PATCH 5/5] module: Remove stop_machine from module unloading

2014-10-12 Thread Rusty Russell
Masami Hiramatsu writes: > Remove stop_machine from module unloading by replacing module_ref > with atomic_t. Note that this can cause a performance regression > on big-SMP machine by direct memory access. For those machines, > you can lockdwon all modules. Since the lockdown skips reference >

Re: [RFC PATCH 5/5] module: Remove stop_machine from module unloading

2014-10-12 Thread Rusty Russell
Masami Hiramatsu masami.hiramatsu...@hitachi.com writes: Remove stop_machine from module unloading by replacing module_ref with atomic_t. Note that this can cause a performance regression on big-SMP machine by direct memory access. For those machines, you can lockdwon all modules. Since the

[RFC PATCH 5/5] module: Remove stop_machine from module unloading

2014-08-25 Thread Masami Hiramatsu
Remove stop_machine from module unloading by replacing module_ref with atomic_t. Note that this can cause a performance regression on big-SMP machine by direct memory access. For those machines, you can lockdwon all modules. Since the lockdown skips reference counting, it'll be more scalable than

[RFC PATCH 5/5] module: Remove stop_machine from module unloading

2014-08-25 Thread Masami Hiramatsu
Remove stop_machine from module unloading by replacing module_ref with atomic_t. Note that this can cause a performance regression on big-SMP machine by direct memory access. For those machines, you can lockdwon all modules. Since the lockdown skips reference counting, it'll be more scalable than