[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Dec 2018 17:11:00 +0000
From: Edward Cree <ecree@...arflare.com>
To: Nadav Amit <namit@...are.com>, Josh Poimboeuf <jpoimboe@...hat.com>
CC: LKML <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH v2 0/4] Static calls
On 12/12/18 05:59, Nadav Amit wrote:
> Thanks for cc’ing me. (I didn’t know about the other patch-sets.)
Well in my case, that's because I haven't posted any yet. (Will follow up
shortly with what I currently have, though it's not pretty.)
Looking at your patches, it seems you've got a much more developed learning
mechanism. Mine on the other hand is brutally simple but runs continuously
(i.e. after we patch we immediately enter the next 'relearning' phase);
since it never does anything but prod a handful of percpu variables, this
shouldn't be too costly.
Also, you've got the macrology for making all indirect calls use this,
whereas at present I just have an open-coded instance on a single call site
(I went with deliver_skb in the networking stack).
So I think where we probably want to go from here is:
1) get Josh's static_calls in. AIUI Linus seems to prefer the out-of-line
approach; I'd say ditch the inline version (at least for now).
2) build a relpolines patch series that uses
i) static_calls for the text-patching part
ii) as much of Nadav's macrology as is applicable
iii) either my or Nadav's learning mechanism; we can experiment with both,
bikeshed it incessantly etc.
Seem reasonable?
-Ed
Powered by blists - more mailing lists