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. If Josh thinks that it would be acceptable to have klp-convert merged even without the tooling, I'm all for it. We're about to start using it at SUSE and staying close to upstream would definitely be better. Miroslav
