Messages in this thread | | | Subject | Re: [PATCH] kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled | From | Joao Moreira <> | Date | Thu, 20 Dec 2018 13:47:53 -0800 |
| |
On 12/20/18 12:33 AM, Miroslav Benes wrote: > On Wed, 19 Dec 2018, Jiri Kosina wrote: > >> On Wed, 19 Dec 2018, Josh Poimboeuf wrote: >> >>> Also the commit message needs an analysis of the performance impacts. >> >> Agreed. Especially as it's expected (*) to be completely in the noise >> particularly for the kernel, it'd be good to have that documented in the >> changelog. >> >> (*) actually measured already for some subset of the IPA optimizations > > Ok, we can do that. I don't expect the results to be different from the > last measurement as Jiri mentions. The sets of disabled optimizations are > similar. > > I'll add it to v2. > > On Wed, 19 Dec 2018, Jiri Kosina wrote: > >> On Wed, 19 Dec 2018, Josh Poimboeuf wrote: >> >>>>> This option only makes sense for source-based patch generation, so isn't >>>>> it a bit premature to make this change without proper source-based patch >>>>> tooling? >>>> >>>> The reality is though that before the full-fledged patch tooling exists, >>>> people are actually already writing livepatches by hand, so this option is >>>> useful for them. >>> >>> Fair enough. > > Yes, that was the reason I sent it. It would not make sense to wait for > the tooling in this case, because -flive-patching is useful even now, > since there is a way to prepare livepatches without any tooling. > >>> Though, upstream, almost everybody seems to use kpatch-build, for which >>> this patch doesn't help. And people will continue to do so until we >>> have decent source-based tooling. Will the klp-convert patches be >>> revived soon? >> >> Let me add Joao, who's working on that. >> >> Joao, I think you had something basically ready for upstream exposure, >> right? > > I think that when Joao posted it a long time ago, the conclusion was that > it would be better to wait for the source-based tooling and have the > complete solution. I may misremember though.
Your memories match mine, Miroslav.
FTR, we recently integrated klp-convert to SLE. There were some fixes in comparison with the version which was submitted upstream, thus a v2 of the patches is necessary.
> > If Josh thinks that it would be acceptable to have klp-convert merged even > without the tooling, I'm all for it. > Of course I can work on that and I'll be glad to do so / submit this new version, if this is now something considered useful.
> We're about to start using it at SUSE and staying close to upstream would > definitely be better. > > Miroslav >
| |