kallsyms_on_each* may schedule so must not be called with interrupts
disabled. The iteration function could disable interrupts, but this
also changes lookup_symbol() to match the change to the other timing
code.
Reported-by: Erhard F.
Link:
https://lore.kernel.org/all/bug-216902-206...@https.bug
On 10/01/2023 05:42:55, Nathan Lynch wrote:
> At the time commit f97bb36f705d ("powerpc/rtas: Turn rtas lock into a
> raw spinlock") was written, the spinlock lockup detection code called
> __delay(), which will not make progress if the timebase is not
> advancing. Since the interprocessor timebase
/mdio-thunder.c| 6 +-
include/linux/fsl/enetc_mdio.h | 21 +-
16 files changed, 766 insertions(+), 432 deletions(-)
---
base-commit: 0a093b2893c711d82622a9ab27da4f1172821336
change-id: 20230112-net-next-c45-seperation-part-2-1b8fbb144687
Best regards,
--
Michael Walle
From: Andrew Lunn
The stmicro stmmac xgmac2 MDIO bus driver can perform both C22 and C45
transfers. Create separate functions for each and register the C45
versions using the new API calls where appropriate.
Signed-off-by: Andrew Lunn
Signed-off-by: Michael Walle
---
drivers/net/ethernet/stmi
From: Andrew Lunn
The enetc MDIO bus driver can perform both C22 and C45 transfers.
Create separate functions for each and register the C45 versions using
the new API calls where appropriate.
This driver is shared with the Felix DSA switch, so update that at the
same time.
Signed-off-by: Andrew
From: Andrew Lunn
The microchip lan743x MDIO bus driver can perform both C22 and C45
transfers in some variants. Create separate functions for each and
register the C45 versions using the new API calls where appropriate.
Signed-off-by: Andrew Lunn
Signed-off-by: Michael Walle
---
drivers/net/
From: Andrew Lunn
The mediatek bus driver can perform both C22 and C45 transfers.
Create separate functions for each and register the C45 versions using
the new API calls.
Signed-off-by: Andrew Lunn
Signed-off-by: Michael Walle
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 178 +++
From: Andrew Lunn
The MDIO mux broadcom iproc can perform both C22 and C45 transfers.
Create separate functions for each and register the C45 versions using
the new API calls.
Signed-off-by: Andrew Lunn
Signed-off-by: Michael Walle
---
Apparently, in the c45 case, the reg value including the M
From: Andrew Lunn
The ipq4019 driver can perform both C22 and C45 transfers. Create
separate functions for each and register the C45 versions using the
new driver API calls.
Signed-off-by: Andrew Lunn
Signed-off-by: Michael Walle
---
drivers/net/mdio/mdio-ipq4019.c | 154
From: Andrew Lunn
The stmmac MDIO bus driver in variant gmac4 can perform both C22 and
C45 transfers. Create separate functions for each and register the
C45 versions using the new API calls where appropriate.
Signed-off-by: Andrew Lunn
Signed-off-by: Michael Walle
---
drivers/net/ethernet/st
From: Andrew Lunn
The aspeed MDIO bus driver can perform both C22 and C45 transfers.
Modify the existing C45 functions to take the devad as a parameter,
and remove the wrappers so there are individual C22 and C45 functions. Add
the C45 functions to the new API calls.
Signed-off-by: Andrew Lunn
From: Andrew Lunn
The cavium IP can perform both C22 and C45 transfers. Create separate
functions for each and register the C45 versions in both the octeon
and thunder bus driver.
Signed-off-by: Andrew Lunn
Signed-off-by: Michael Walle
---
drivers/net/mdio/mdio-cavium.c | 111 ++
From: Andrew Lunn
The MDIO over I2C bus driver can perform both C22 and C45 transfers.
Create separate functions for each and register the C45 versions using
the new API calls.
Signed-off-by: Andrew Lunn
Signed-off-by: Michael Walle
---
drivers/net/mdio/mdio-i2c.c | 32 +++
Fix build errors in soc/fsl/qe/usb.c when QUICC_ENGINE is not set.
This happens when PPC_EP88XC is set, which selects CPM1 & CPM.
When CPM is set, USB_FSL_QE can be set without QUICC_ENGINE
being set. When USB_FSL_QE is set, QE_USB deafults to y, which
causes build errors when QUICC_ENGINE is not s
Laurent Dufour writes:
> On 10/01/2023 05:42:55, Nathan Lynch wrote:
>> --- a/arch/powerpc/include/asm/rtas-types.h
>> +++ b/arch/powerpc/include/asm/rtas-types.h
>> @@ -18,7 +18,7 @@ struct rtas_t {
>> unsigned long entry;/* physical address pointer */
>> unsigned long base;
On Thu, Jan 12, 2023 at 4:06 AM Nathan Chancellor wrote:
>
> When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, there
> are several warnings in the PowerPC vDSO:
>
> clang-16: error: -Wl,-soname=linux-vdso32.so.1: 'linker' input unused
> [-Werror,-Wunused-command-line-argument]
>
Hi Sedat,
On Thu, Jan 12, 2023 at 07:02:30PM +0100, Sedat Dilek wrote:
> On Thu, Jan 12, 2023 at 4:06 AM Nathan Chancellor wrote:
> >
> > When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, there
> > are several warnings in the PowerPC vDSO:
> >
> > clang-16: error: -Wl,-soname=lin
On Wed, Jan 11, 2023 at 03:27:51PM -0800, Sathyanarayanan Kuppuswamy wrote:
> On 1/11/23 3:10 PM, Bjorn Helgaas wrote:
> > On Wed, Jan 11, 2023 at 01:42:21PM -0800, Sathyanarayanan Kuppuswamy wrote:
> >> On 1/11/23 12:31 PM, Vidya Sagar wrote:
> >>> As the ECRC configuration bits are part of AER re
On Thu, Jan 12, 2023 at 08:54:26PM +1000, Nicholas Piggin wrote:
> kallsyms_on_each* may schedule so must not be called with interrupts
> disabled. The iteration function could disable interrupts, but this
> also changes lookup_symbol() to match the change to the other timing
> code.
>
> Reported-
On Thu, Jan 12, 2023 at 12:51:11PM +0530, Vidya Sagar wrote:
> As the ECRC configuration bits are part of AER registers, configure
> ECRC only if AER is natively owned by the kernel.
>
> Signed-off-by: Vidya Sagar
Applied to pci/aer for v6.3, thanks!
> ---
> v2:
> * Updated kernel-parameters.tx
On Thu, Jan 12, 2023 at 7:21 PM Nathan Chancellor wrote:
>
> Hi Sedat,
>
> On Thu, Jan 12, 2023 at 07:02:30PM +0100, Sedat Dilek wrote:
> > On Thu, Jan 12, 2023 at 4:06 AM Nathan Chancellor wrote:
> > >
> > > When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, there
> > > are several
From: Xiaowei Bao
Add PCIe EP mode support for ls1028a.
Signed-off-by: Xiaowei Bao
Signed-off-by: Hou Zhiqiang
Signed-off-by: Frank Li
Acked-by: Roy Zang
---
Added
Signed-off-by: Frank Li
Acked-by: Roy Zang
All other patches were already accepte by maintainer in
https://lore.kernel
From: Guanhua Gao
Set DMA mask and coherent DMA mask to enable 64-bit addressing.
Signed-off-by: Guanhua Gao
Signed-off-by: Hou Zhiqiang
Signed-off-by: Frank Li
---
drivers/pci/controller/dwc/pci-layerscape-ep.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/pci/controller/d
From: Xiaowei Bao
When a link down or hot reset event occurs, the PCI Express EP
controller's Link Capabilities Register should retain the values of
the Maximum Link Width and Supported Link Speed configured by RCW.
Signed-off-by: Xiaowei Bao
Signed-off-by: Hou Zhiqiang
Signed-off-by: Frank Li
On Thu, 29 Dec 2022 19:01:31 -0500, Sean Anderson wrote:
> This adds a binding for the SerDes module found on QorIQ processors.
> Each phy is a subnode of the top-level device, possibly supporting
> multiple lanes and protocols. This "thick" #phy-cells is used due to
> allow for better organizati
On Mon, Jan 09, 2023 at 03:41:31PM +, Frank Li wrote:
> >
> > From: Xiaowei Bao
> >
> > Add PCIe EP mode support for ls1028a.
> >
> > Signed-off-by: Xiaowei Bao
> > Signed-off-by: Hou Zhiqiang
> > ---
> >
> > All other patches were already accepte by maintainer in
> > https://lore.kernel
vmlinux.o: warning: objtool: mwait_idle+0x5: call to
current_set_polling_and_test() leaves .noinstr.text section
vmlinux.o: warning: objtool: acpi_processor_ffh_cstate_enter+0xc5: call to
current_set_polling_and_test() leaves .noinstr.text section
vmlinux.o: warning: objtool: cpu_idle_poll.isra.0
All the idle routines are called with RCU disabled, as such there must
not be any tracing inside.
While there; clean-up the io-port idle thing.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rafael J. Wysocki
Acked-by: Frederic Weisbecker
Tested-by: Tony Lindgren
Tested-by: Ulf Hansson
---
None of these functions should ever be ran with RCU disabled anymore.
Specifically, do_handle_IPI() is only called from handle_IPI() which
explicitly does irq_enter()/irq_exit() which ensures RCU is watching.
The problem with smp_cross_call() was, per commit 7c64cc0531fa ("arm: Use
_rcuidle for s
cpuidle_state::enter() methods should be IRQ invariant.
Additionally make sure to use raw_local_irq_*() methods since this
cpuidle callback will be called with RCU already disabled.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Rafael J. Wysocki
Reviewed-by: Frederic Weisbecker
Tested-by:
Make cpuidle_enter_state() consistent with the s2idle variant and
verify ->enter() always returns with interrupts disabled.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rafael J. Wysocki
Acked-by: Frederic Weisbecker
Tested-by: Tony Lindgren
Tested-by: Ulf Hansson
---
drivers/cpuidle/cpui
arch_cpu_idle() is a very simple idle interface and exposes only a
single idle state and is expected to not require RCU and not do any
tracing/instrumentation.
As such, omap_sram_idle() is not a valid implementation. Replace it
with the simple (shallow) omap3_do_wfi() call. Leaving the more
compli
vmlinux.o: warning: objtool: in_entry_stack+0x9: call to
__this_cpu_preempt_check() leaves .noinstr.text section
vmlinux.o: warning: objtool: default_do_nmi+0x10: call to
__this_cpu_preempt_check() leaves .noinstr.text section
vmlinux.o: warning: objtool: fpu_idle_fpregs+0x41: call to
__this_cpu
Current arch_cpu_idle() is called with IRQs disabled, but will return
with IRQs enabled.
However, the very first thing the generic code does after calling
arch_cpu_idle() is raw_local_irq_disable(). This means that
architectures that can idle with IRQs disabled end up doing a
pointless 'enable-dis
The PM notifiers should no longer be ran with RCU disabled (per the
previous patches), as such this hack is no longer required either.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rafael J. Wysocki
Acked-by: Frederic Weisbecker
Tested-by: Tony Lindgren
Tested-by: Ulf Hansson
---
drivers/p
vmlinux.o: warning: objtool: io_idle+0xc: call to __inb.isra.0() leaves
.noinstr.text section
vmlinux.o: warning: objtool: acpi_idle_enter+0xfe: call to num_online_cpus()
leaves .noinstr.text section
vmlinux.o: warning: objtool: acpi_idle_enter+0x115: call to
acpi_idle_fallback_to_c1.isra.0() le
For all cpuidle drivers that do not use CPUIDLE_FLAG_RCU_IDLE (iow,
the simple ones) make sure all the functions are marked __cpuidle.
( due to lack of noinstr validation on these platforms it is entirely
possible this isn't complete )
Signed-off-by: Peter Zijlstra (Intel)
---
arch/arm/kernel
For testing purposes.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rafael J. Wysocki
Acked-by: Frederic Weisbecker
Tested-by: Tony Lindgren
Tested-by: Ulf Hansson
---
drivers/idle/intel_idle.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/idle/intel_idle.c
Tracing (kprobes included) and other compiler instrumentation relies
on a normal kernel runtime. Therefore all functions that disable RCU
should be noinstr, as should all functions that are called while RCU
is disabled.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle.c | 37 +
The problem, per commit fc98c3c8c9dc ("printk: use rcuidle console
tracepoint"), was printk usage from the cpuidle path where RCU was
already disabled.
Per the patches earlier in this series, this is no longer the case.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Sergey Senozhatsky
Acked
Doing RCU-idle outside the driver, only to then temporarily enable it
again, at least twice, before going idle is daft.
Notably both cpu_pm_enter() and cpu_cluster_pm_enter() implicity
re-enable RCU.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Frederic Weisbecker
Acked-by: Rafael J. Wyso
clang-14 allyesconfig gives:
vmlinux.o: warning: objtool: emulator_cmpxchg_emulated+0x705: call to
__ubsan_handle_load_invalid_value() with UACCESS enabled
vmlinux.o: warning: objtool: paging64_update_accessed_dirty_bits+0x39e: call to
__ubsan_handle_load_invalid_value() with UACCESS enabled
vml
Per commit 56e62a737028 ("s390: convert to generic entry") the last
and only callers of trace_hardirqs_{on,off}_caller() went away, clean
up.
Cc: Sven Schnelle
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/trace/trace_preemptirq.c | 29 -
1 file changed, 29 dele
For all cpuidle drivers that use CPUIDLE_FLAG_RCU_IDLE, ensure that
all functions that call ct_cpuidle_enter() are marked __cpuidle.
( due to lack of noinstr validation on these platforms it is entirely
possible this isn't complete )
Signed-off-by: Peter Zijlstra (Intel)
---
arch/arm/mach-imx
From: Tony Lindgren
OMAP4 uses full SoC suspend modes as idle states, as such it needs the
whole power-domain and clock-domain code from the idle path.
All that code is not suitable to run with RCU disabled, as such push
RCU-idle deeper still.
Signed-off-by: Tony Lindgren
Signed-off-by: Peter
No callers left that have already disabled RCU.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Mark Rutland
Acked-by: Rafael J. Wysocki
Acked-by: Frederic Weisbecker
Tested-by: Tony Lindgren
Tested-by: Ulf Hansson
---
kernel/time/tick-broadcast-hrtimer.c | 29
vmlinux.o: warning: objtool: intel_idle_irq+0x10c: call to
trace_hardirqs_off() leaves .noinstr.text section
As per commit 32d4fd5751ea ("cpuidle,intel_idle: Fix
CPUIDLE_FLAG_IRQ_ENABLE"):
"must not have tracing in idle functions"
Clearly people can't read and tinker along until splat dissa
OMAP was the one and only user.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Ulf Hansson
Acked-by: Rafael J. Wysocki
Acked-by: Frederic Weisbecker
Tested-by: Tony Lindgren
Tested-by: Ulf Hansson
---
drivers/clk/clk.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--
The perf_lopwr_cb() is called from the idle routines; there is no RCU
there, we must not enter tracing.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rafael J. Wysocki
Acked-by: Frederic Weisbecker
Tested-by: Tony Lindgren
Tested-by: Ulf Hansson
---
arch/x86/events/amd/brs.c | 13
KASAN cannot just hijack the mem*() functions, it needs to emit
__asan_mem*() variants if it wants instrumentation (other sanitizers
already do this).
vmlinux.o: warning: objtool: sync_regs+0x24: call to memcpy() leaves
.noinstr.text section
vmlinux.o: warning: objtool: vc_switch_off_ist+0xbe: ca
arch_cpu_idle() is a very simple idle interface and exposes only a
single idle state and is expected to not require RCU and not do any
tracing/instrumentation.
As such, omap2_pm_idle() is not a valid implementation. Replace it
with a simple (shallow) omap2_do_wfi() call.
Omap2 doesn't have a cpui
vmlinux.o: warning: objtool: __ct_user_enter+0x72: call to
__kasan_check_write() leaves .noinstr.text section
vmlinux.o: warning: objtool: __ct_user_exit+0x47: call to __kasan_check_write()
leaves .noinstr.text section
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/context_tracking.c | 12
Now that arch_cpu_idle() is expected to return with IRQs disabled,
avoid the useless STI/CLI dance.
Per the specs this is supposed to work, but nobody has yet relied up
this behaviour so broken implementations are possible.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rafael J. Wysocki
Acked
vmlinux.o: warning: objtool: intel_idle_ibrs+0x17: call to spec_ctrl_current()
leaves .noinstr.text section
vmlinux.o: warning: objtool: intel_idle_ibrs+0x27: call to wrmsrl.constprop.0()
leaves .noinstr.text section
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rafael J. Wysocki
Acked-by: F
vmlinux.o: warning: objtool: __halt+0x2c: call to hcall_func.constprop.0()
leaves .noinstr.text section
vmlinux.o: warning: objtool: __halt+0x3f: call to __tdx_hypercall() leaves
.noinstr.text section
vmlinux.o: warning: objtool: __tdx_hypercall+0x66: call to
__tdx_hypercall_failed() leaves .noi
ARCH_WANTS_NO_INSTR (a superset of CONFIG_GENERIC_ENTRY) disallows any
and all tracing when RCU isn't enabled.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rafael J. Wysocki
Acked-by: Frederic Weisbecker
Tested-by: Tony Lindgren
Tested-by: Ulf Hansson
---
include/linux/tracepoint.h | 15
The whole disable-RCU, enable-IRQS dance is very intricate since
changing IRQ state is traced, which depends on RCU.
Add two helpers for the cpuidle case that mirror the entry code.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rafael J. Wysocki
Acked-by: Frederic Weisbecker
Tested-by: Tony
Add a few words on noinstr / __cpuidle usage.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle.c | 12
include/linux/compiler_types.h | 10 ++
2 files changed, 22 insertions(+)
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -252
The __cpuidle functions will become a noinstr class, as such they need
explicit annotations.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Rafael J. Wysocki
Acked-by: Frederic Weisbecker
Tested-by: Tony Lindgren
Tested-by: Ulf Hansson
---
drivers/cpuidle/poll_state.c |6 +-
1 fi
Doing RCU-idle outside the driver, only to then teporarily enable it
again before going idle is daft.
Notably the cpu_pm_*() calls implicitly re-enable RCU for a bit.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Frederic Weisbecker
Reviewed-by: Tony Lindgren
Acked-by: Rafael J. Wysocki
Hi All!
The (hopefully) final respin of cpuidle vs rcu cleanup patches. Barring any
objections I'll be queueing these patches in tip/sched/core in the next few
days.
v2: https://lkml.kernel.org/r/20220919095939.761690...@infradead.org
These here patches clean up the mess that is cpuidle vs rcuid
Typical boot time setup; no need to suffer an indirect call for that.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Frederic Weisbecker
Reviewed-by: Rafael J. Wysocki
Tested-by: Tony Lindgren
Tested-by: Ulf Hansson
---
arch/x86/kernel/process.c | 50 +--
vmlinux.o: warning: objtool: intel_idle_s2idle+0xd5: call to fpu_idle_fpregs()
leaves .noinstr.text section
vmlinux.o: warning: objtool: intel_idle_xstate+0x11: call to fpu_idle_fpregs()
leaves .noinstr.text section
vmlinux.o: warning: objtool: fpu_idle_fpregs+0x9: call to xfeatures_in_use()
lea
Robot reported that trace_hardirqs_{on,off}() tickle the forbidden
_rcuidle() tracepoint through local_irq_{en,dis}able().
For 'sane' configs, these calls will only happen with RCU enabled and
as such can use the regular tracepoint. This also means it's possible
to trace them from NMI context agai
Doing RCU-idle outside the driver, only to then temporarily enable it
again before going idle is daft.
Notably: this converts all dt_init_idle_driver() and
__CPU_PM_CPU_IDLE_ENTER() users for they are inextrably intertwined.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rafael J. Wysocki
Acke
OMAP was the one and only user.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Ulf Hansson
Acked-by: Rafael J. Wysocki
Acked-by: Frederic Weisbecker
Tested-by: Tony Lindgren
Tested-by: Ulf Hansson
---
arch/arm/mach-omap2/powerdomain.c | 10 +-
drivers/base/power/runtime.c
OMAP3 uses full SoC suspend modes as idle states, as such it needs the
whole power-domain and clock-domain code from the idle path.
All that code is not suitable to run with RCU disabled, as such push
RCU-idle deeper still.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Tony Lindgren
Acked-
Quoting Peter Zijlstra (2023-01-12 11:43:55)
> OMAP was the one and only user.
>
> Signed-off-by: Peter Zijlstra (Intel)
> Reviewed-by: Ulf Hansson
> Acked-by: Rafael J. Wysocki
> Acked-by: Frederic Weisbecker
> Tested-by: Tony Lindgren
> Tested-by: Ulf Hansson
> ---
Acked-by: Stephen Boyd
On 1/12/23 07:15, Michael Walle wrote:
From: Andrew Lunn
The MDIO mux broadcom iproc can perform both C22 and C45 transfers.
Create separate functions for each and register the C45 versions using
the new API calls.
Signed-off-by: Andrew Lunn
Signed-off-by: Michael Walle
---
Apparently, in th
When it saves the branch stack to the perf sample data, it needs to
update the sample flags and the dynamic size. To make sure this,
add the perf_sample_save_brstack() helper and convert all call sites.
Cc: linuxppc-dev@lists.ozlabs.org
Cc: x...@kernel.org
Suggested-by: Peter Zijlstra
Signed-off
[ Adding linux-arch, which is relevant but not very specific, and the
arm64 and powerpc maintainers that are the more specific cases for an
architecture where this might actually matter.
See
https://lore.kernel.org/all/CAGudoHHx0Nqg6DE70zAVA75eV-HXfWyhVMWZ-aSeOofkA_=w...@mail.gmail.com
> Yeah, if it was ia64-only, it's a non-issue these days. It's dead and
> in pure maintenance mode from a kernel perspective (if even that).
There's not much "simultaneous" in the SMT on ia64. One thread in a
spin loop will hog the core until the h/w switches to the other thread some
number of cyc
On Thu, Jan 12, 2023 at 6:31 PM Luck, Tony wrote:
>
> There's not much "simultaneous" in the SMT on ia64.
Oh, I forgot about the whole SoEMT fiasco.
Yeah, that might make ia64 act a bit differently here.
But I don't think anybody cares any more, so I don't think that merits
making this a per-ar
On Fri Jan 13, 2023 at 10:13 AM AEST, Linus Torvalds wrote:
> [ Adding linux-arch, which is relevant but not very specific, and the
> arm64 and powerpc maintainers that are the more specific cases for an
> architecture where this might actually matter.
>
> See
>
>
> https://lore.kernel.o
On Thu, Jan 12, 2023 at 7:12 PM Mateusz Guzik wrote:
>
> I did not want to make such a change without redoing the ThunderX2
> benchmark, or at least something else arm64-y. I may be able to bench it
> tomorrow on whatever arm-y stuff can be found on Amazon's EC2, assuming
> no arm64 people show up
On Thu, Jan 12, 2023 at 9:20 PM Nicholas Piggin wrote:
>
> Actually what we'd really want is an arch specific implementation of
> lockref.
The problem is mainly that then you need to generate the asm versions
of all those different CMPXCHG_LOOP() variants.
They are all fairly simple, though, an
On Fri Jan 13, 2023 at 2:15 PM AEST, Linus Torvalds wrote:
> On Thu, Jan 12, 2023 at 9:20 PM Nicholas Piggin wrote:
> >
> > Actually what we'd really want is an arch specific implementation of
> > lockref.
>
> The problem is mainly that then you need to generate the asm versions
> of all those dif
On Fri, 13 Jan 2023 at 01:31, Luck, Tony wrote:
>
> > Yeah, if it was ia64-only, it's a non-issue these days. It's dead and
> > in pure maintenance mode from a kernel perspective (if even that).
>
> There's not much "simultaneous" in the SMT on ia64. One thread in a
> spin loop will hog the core u
78 matches
Mail list logo