similar to: [PATCH v5 0/9] x86: macrofying inline asm for better compilation

* Masahiro Yamada <yamada.masahiro at socionext.com> wrote: > This series reverts the in-kernel workarounds for inlining issues. > > The commit description of 77b0bf55bc67 mentioned > "We also hope that GCC will eventually get fixed,..." > > Now, GCC provides a solution. > > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html > explains the new

This series reverts the in-kernel workarounds for inlining issues. The commit description of 77b0bf55bc67 mentioned "We also hope that GCC will eventually get fixed,..." Now, GCC provides a solution. https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html explains the new "asm inline" syntax. The performance issue will be eventually solved. [About Code cleanups] I know Nadam

This series reverts the in-kernel workarounds for inlining issues. The commit description of 77b0bf55bc67 mentioned "We also hope that GCC will eventually get fixed,..." Now, GCC provides a solution. https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html explains the new "asm inline" syntax. The performance issue will be eventually solved. [About Code cleanups] I know Nadam

On Sun, Dec 16, 2018 at 12:29 PM Nadav Amit <namit at vmware.com> wrote: > > > On Dec 15, 2018, at 6:50 PM, Masahiro Yamada <yamada.masahiro at socionext.com> wrote: > > > > Revert the following 9 commits: > > > > [1] 5bdcd510c2ac ("x86/jump-labels: Macrofy inline assembly code to > > work around GCC inlining bugs") > > >

Hi people, this is an attempt to see whether gcc's inline asm heuristic when estimating inline asm statements' cost for better inlining can be improved. AFAIU, the problematic arises when one ends up using a lot of inline asm statements in the kernel but due to the inline asm cost estimation heuristic which counts lines, I think, for example like in this here macro:

Revert the following 9 commits: [1] 5bdcd510c2ac ("x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs") This was partially reverted because it made good cleanups irrespective of the inlining issue; the error message is still unneeded, and the conversion to STATIC_BRANCH_{NOP,JUMP} should be kept. [2] d5a581d84ae6 ("x86/cpufeature:

Revert the following commits: - 5bdcd510c2ac9efaf55c4cbd8d46421d8e2320cd ("x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs") - d5a581d84ae6b8a4a740464b80d8d9cf1e7947b2 ("x86/cpufeature: Macrofy inline assembly code to work around GCC inlining bugs") - 0474d5d9d2f7f3b11262f7bf87d0e7314ead9200. ("x86/extable: Macrofy inline assembly

Revert the following commits: - 5bdcd510c2ac9efaf55c4cbd8d46421d8e2320cd ("x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs") - d5a581d84ae6b8a4a740464b80d8d9cf1e7947b2 ("x86/cpufeature: Macrofy inline assembly code to work around GCC inlining bugs") - 0474d5d9d2f7f3b11262f7bf87d0e7314ead9200. ("x86/extable: Macrofy inline assembly

On Mon, Jun 04, 2018 at 04:21:22AM -0700, Nadav Amit wrote: > This patch-set deals with an interesting yet stupid problem: kernel code > that does not get inlined despite its simplicity. There are several > causes for this behavior: "cold" attribute on __init, different function > optimization levels; conditional constant computations based on > __builtin_constant_p(); and

* Nadav Amit <namit at vmware.com> wrote: > > I ran some limited number of benchmarks, and in general the performance > > impact is not very notable. You can still see >10 cycles shaved off some > > syscalls that manipulate page-tables (e.g., mprotect()), in which > > paravirt caused many functions not to be inlined. In addition this > > patch-set can

* Nadav Amit <namit at vmware.com> wrote: > Ping. Masahiro Yamada noted that some Reviewed-by tags were not added - could you please double check past mails and add them and re-send against the latest kernel? Thanks, Ingo

On Tue, Sep 18, 2018 at 2:28 PM, Nadav Amit <namit at vmware.com> wrote: > This patch-set deals with an interesting yet stupid problem: kernel code > that does not get inlined despite its simplicity. There are several > causes for this behavior: "cold" attribute on __init, different function > optimization levels; conditional constant computations based on >

From: Nadav Amit > Sent: 17 May 2018 17:14 > This patch-set deals with an interesting yet stupid problem: kernel code > that does not get inlined despite its simplicity. There are several > causes for this behavior: "cold" attribute on __init, different function > optimization levels; conditional constant computations based on > __builtin_constant_p(); and finally large

On Wed, Dec 19, 2018 at 5:26 AM Nadav Amit <namit at vmware.com> wrote: > > > On Dec 17, 2018, at 8:03 AM, Masahiro Yamada <yamada.masahiro at socionext.com> wrote: > > > > This series reverts the in-kernel workarounds for inlining issues. > > > > The commit description of 77b0bf55bc67 mentioned > > "We also hope that GCC will eventually get

There are cases where a guest tries to switch spinlocks to bare metal behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this has the downside of falling back to unfair test and set scheme for qspinlocks due to virt_spin_lock() detecting the virtualized environment. Add a static key controlling whether virt_spin_lock() should be called or not. When running on bare metal set

On 09/06/2017 11:29 AM, Juergen Gross wrote: > There are cases where a guest tries to switch spinlocks to bare metal > behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this > has the downside of falling back to unfair test and set scheme for > qspinlocks due to virt_spin_lock() detecting the virtualized > environment. > > Add a static key controlling

On 09/06/2017 11:29 AM, Juergen Gross wrote: > There are cases where a guest tries to switch spinlocks to bare metal > behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this > has the downside of falling back to unfair test and set scheme for > qspinlocks due to virt_spin_lock() detecting the virtualized > environment. > > Add a static key controlling

With CONFIG_PARAVIRT, the kernel .text is littered with a bunch of calls to pv_irq_ops function pointers, like: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) In non-Xen paravirt environments -- including native, KVM, Hyper-V, and VMware -- the above code gets patched by native_patch() to look like this instead: pushfq pop %rax nopl 0x0(%rax,%rax,1) So in most scenarios,

From: Josh Poimboeuf <jpoimboe at redhat.com> [ Upstream commit 083db6764821996526970e42d09c1ab2f4155dd4 ] The __raw_callee_save_*() functions have an ELF symbol size of zero, which confuses objtool and other tools. Fixes a bunch of warnings like the following: arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_pte_val() is missing an ELF size annotation

From: Josh Poimboeuf <jpoimboe at redhat.com> [ Upstream commit 083db6764821996526970e42d09c1ab2f4155dd4 ] The __raw_callee_save_*() functions have an ELF symbol size of zero, which confuses objtool and other tools. Fixes a bunch of warnings like the following: arch/x86/xen/mmu_pv.o: warning: objtool: __raw_callee_save_xen_pte_val() is missing an ELF size annotation