Messages in this thread | | | Date | Tue, 11 Dec 2018 12:05:21 -0600 | From | Josh Poimboeuf <> | Subject | Re: [PATCH v2 0/4] Static calls |
| |
On Fri, Dec 07, 2018 at 04:06:32PM +0000, Edward Cree wrote: > Sorry if this has been pointed out before (it's a very long thread), but > in the out-of-line implementation, it appears that static_call_update() > never alters key->func. Am I right in thinking that this should be > fixed by adding 'WRITE_ONCE(key->func, func);' just after the call to > arch_static_call_transform() on line 159 of include/linux/static_call.h?
Yes, you're right about both bugs in the out-of-line case: key->func needs to be written, and __static_call_update() needs to be called by static_call_update. I was so focused on getting the inline case working that I overlooked those.
> Some background (why does key->func matter for the > CONFIG_HAVE_STATIC_CALL_OUTLINE case?): I am experimenting with > combining these static calls with the 'indirect call wrappers' notion > that Paolo Abeni has been working on [1], using runtime instrumentation > to determine a list of potential callees. (This allows us to cope with > cases where the callees are in modules, or where different workloads may > use different sets of callees for a given call site, neither of which is > handled by Paolo's approach). > The core of my design looks something like: > > static int dynamic_call_xyz(int (*func)(some_args), some_args) > { > if (func == dynamic_call_xyz_1.func) > return static_call(dynamic_call_xyz_1, some_args); > if (func == dynamic_call_xyz_2.func) > return static_call(dynamic_call_xyz_2, some_args); > return (*func)(some_args); > } > > albeit with a bunch of extra (and currently rather ugly) stuff to collect > the statistics needed to decide what to put in the static call keys, and > mechanisms (RCU in my current case) to ensure that the static call isn't > changed between checking its .func and actually calling it. > > -Ed > > PS: not on list, please keep me in CC. > > [1] https://lwn.net/Articles/773985/
Thanks, this sounds very interesting. Adding Nadav to CC, as he has been looking at a different approach to solving the same problem:
https://lkml.kernel.org/r/20181018005420.82993-1-namit@vmware.com
-- Josh
| |