Generic kernel features that need architecture(mips) support
Subsystems (3)
Hi,
If there is anything wrong, please report it in this thread:
https://marc.info/?t=143332955700003
The meaning of entries in the tables is:
| ok | # feature supported by the architecture
|TODO| # feature not yet supported by the architecture
| .. | # feature cannot be supported by the hardware#
# Kernel feature support matrix of the 'mips' architecture:
#
core/ BPF-JIT : ok | HAVE_BPF_JIT # arch supports BPF JIT optimizations
core/ generic-idle-thread : ok | GENERIC_SMP_IDLE_THREAD # arch makes use of the generic SMP idle thread facility
core/ jump-labels : ok | HAVE_ARCH_JUMP_LABEL # arch supports live patched, high efficiency branches
core/ tracehook : ok | HAVE_ARCH_TRACEHOOK # arch supports tracehook (ptrace) register handling APIs
debug/ kgdb : ok | HAVE_ARCH_KGDB # arch supports the kGDB kernel debugger
debug/ kprobes : ok | HAVE_KPROBES # arch supports live patched kernel probe
debug/ kretprobes : ok | HAVE_KRETPROBES # arch supports kernel function-return probes
debug/ stackprotector : ok | HAVE_CC_STACKPROTECTOR # arch supports compiler driven stack overflow protection
io/ dma-api-debug : ok | HAVE_DMA_API_DEBUG # arch supports DMA debug facilities
io/ dma-contiguous : ok | HAVE_DMA_CONTIGUOUS # arch supports the DMA CMA (continuous memory allocator)
io/ dma_map_attrs : ok | HAVE_DMA_ATTRS # arch provides dma_*map*_attrs() APIs
locking/ lockdep : ok | LOCKDEP_SUPPORT # arch supports the runtime locking correctness debug facility
seccomp/ seccomp-filter : ok | HAVE_ARCH_SECCOMP_FILTER # arch supports seccomp filters
time/ arch-tick-broadcast : ok | ARCH_HAS_TICK_BROADCAST # arch provides tick_broadcast()
time/ clockevents : ok | GENERIC_CLOCKEVENTS # arch support generic clock events
time/ context-tracking : ok | HAVE_CONTEXT_TRACKING # arch supports context tracking for NO_HZ_FULL
time/ irq-time-acct : ok | HAVE_IRQ_TIME_ACCOUNTING # arch supports precise IRQ time accounting
time/ modern-timekeeping : ok | !ARCH_USES_GETTIMEOFFSET # arch does not use arch_gettimeoffset() anymore
time/ virt-cpuacct : ok | HAVE_VIRT_CPU_ACCOUNTING # arch supports precise virtual CPU time accounting
vm/ ELF-ASLR : ok | ARCH_HAS_ELF_RANDOMIZE # arch randomizes the stack, heap and binary images of ELF binaries
vm/ numa-memblock : ok | HAVE_MEMBLOCK_NODE_MAP # arch supports NUMA aware memblocks
vm/ pmdp_splitting_flush : ok | __HAVE_ARCH_PMDP_SPLITTING_FLUSH # arch supports the pmdp_splitting_flush() VM API
vm/ THP : ok | HAVE_ARCH_TRANSPARENT_HUGEPAGE # arch supports transparent hugepages
debug/ gcov-profile-all : TODO | ARCH_HAS_GCOV_PROFILE_ALL # arch supports whole-kernel GCOV code coverage profiling
debug/ KASAN : TODO | HAVE_ARCH_KASAN # arch supports the KASAN runtime memory checker
debug/ kprobes-on-ftrace : TODO | HAVE_KPROBES_ON_FTRACE # arch supports combined kprobes and ftrace live patching
debug/ optprobes : TODO | HAVE_OPTPROBES # arch supports live patched optprobes
debug/ uprobes : TODO | ARCH_SUPPORTS_UPROBES # arch supports live patched user probes
debug/ user-ret-profiler : TODO | HAVE_USER_RETURN_NOTIFIER # arch supports user-space return from system call profiler
io/ sg-chain : TODO | ARCH_HAS_SG_CHAIN # arch supports chained scatter-gather lists
lib/ strncasecmp : TODO | __HAVE_ARCH_STRNCASECMP # arch provides an optimized strncasecmp() function
locking/ cmpxchg-local : TODO | HAVE_CMPXCHG_LOCAL # arch supports the this_cpu_cmpxchg() API
locking/ queued-rwlocks : TODO | ARCH_USE_QUEUED_RWLOCKS # arch supports queued rwlocks
locking/ queued-spinlocks : TODO | ARCH_USE_QUEUED_SPINLOCKS # arch supports queued spinlocks
locking/ rwsem-optimized : TODO | Optimized asm/rwsem.h # arch provides optimized rwsem APIs
perf/ kprobes-event : TODO | HAVE_REGS_AND_STACK_ACCESS_API # arch supports kprobes with perf events
perf/ perf-regs : TODO | HAVE_PERF_REGS # arch supports perf events register access
perf/ perf-stackdump : TODO | HAVE_PERF_USER_STACK_DUMP # arch supports perf events stack dumps
sched/ numa-balancing : TODO | ARCH_SUPPORTS_NUMA_BALANCING # arch supports NUMA balancing
vm/ huge-vmap : TODO | HAVE_ARCH_HUGE_VMAP # arch supports the ioremap_pud_enabled() and ioremap_pmd_enabled() VM APIs
vm/ ioremap_prot : TODO | HAVE_IOREMAP_PROT # arch has ioremap_prot()
vm/ PG_uncached : TODO | ARCH_USES_PG_UNCACHED # arch supports the PG_uncached page flag
vm/ pte_special : TODO | __HAVE_ARCH_PTE_SPECIAL # arch supports the pte_special()/pte_mkspecial() VM APIsQuoted 5 lines · Xose Vazquez Perez
If there is anything wrong, please report it in this thread:
https://marc.info/?t=143332955700003locking/ cmpxchg-local : TODO |
HAVE_CMPXCHG_LOCAL# arch supports thethis_cpu_cmpxchg()API
This one was easy - we have the functions in the code just no "select HAVE_CMPXCHG_LOCAL" Kconfig.
How are the documentation files in Documentation/features/ maintained? They were automatically generated so I wonder if I have to take care of anything.
Ralf
HAVE_CMPXCHG_LOCAL arch support.
Quoted 10 lines · Ralf Baechle
Quoted 5 lines · Xose Vazquez Perez
If there is anything wrong, please report it in this thread:
https://marc.info/?t=143332955700003locking/ cmpxchg-local : TODO |
HAVE_CMPXCHG_LOCAL# arch supports thethis_cpu_cmpxchg()APIThis one was easy - we have the functions in the code just no "select
HAVE_CMPXCHG_LOCAL"Kconfig.
Something's wrong there. The new file Documentation/features/locking/cmpxchg-local/arch-support.txt in linux-next claims correctly that only s390 and x86 define HAVE_CMPXCHG_LOCAL. And a git grep -w cmpxchg_local finds that in addition to these alpha, arm, arm64, avr32, blackfin, c6x, frv, ia64, m32r, m68k, mips, parisc, powerpc, sparc, unicore32 and xtensa define cmpxchg_local.
These architectures seem to not define cmpxchg_local in their arch/ dir:
arc cris hexagon metag microblaze mn10300 nios2 openrisc score sh tile um
Microblaze and nios2 include <asm-generic/cmpxchg.h> into their arch cmpxchg.h so they get a definition of these functions but don't define HAVE_CMPXCHG_LOCAL. Peter Zijlstra said it the local versions are ~ 20 cycles faster on x86 than the "global" version. But I've found one user of cmpxchg_local, mm/vmstat.c and one user of cmpxchg64_local, drivers/iommu/intel-iommu.c. Sure, fixing the issue was trivial for me on MIPS but is having cmpxchg{,64}_local actually worth it?
Cheers,
Ralf
Re: HAVE_CMPXCHG_LOCAL arch support.
Quoted 24 lines · Ralf Baechle
Quoted 10 lines · Ralf Baechle
Quoted 5 lines · Xose Vazquez Perez
If there is anything wrong, please report it in this thread:
https://marc.info/?t=143332955700003locking/ cmpxchg-local : TODO |
HAVE_CMPXCHG_LOCAL# arch supports thethis_cpu_cmpxchg()APIThis one was easy - we have the functions in the code just no "select
HAVE_CMPXCHG_LOCAL"Kconfig.Something's wrong there. The new file
Documentation/features/locking/cmpxchg-local/arch-support.txtin linux-next claims correctly that only s390 and x86 defineHAVE_CMPXCHG_LOCAL. And a git grep -wcmpxchg_localfinds that in addition to these alpha, arm, arm64, avr32, blackfin, c6x, frv, ia64, m32r, m68k, mips, parisc, powerpc, sparc, unicore32 and xtensa definecmpxchg_local.These architectures seem to not define
cmpxchg_localin theirarch/dir:arc cris hexagon metag microblaze mn10300 nios2 openrisc score sh tile um
Quoted 7 lines
Microblaze and nios2 include <
asm-generic/cmpxchg.h> into their archcmpxchg.hso they get a definition of these functions but don't defineHAVE_CMPXCHG_LOCAL. Peter Zijlstra said it the local versions are ~ 20 cycles faster on x86 than the "global" version. But I've found one user ofcmpxchg_local,mm/vmstat.cand one user ofcmpxchg64_local,drivers/iommu/intel-iommu.c. Sure, fixing the issue was trivial for me on MIPS but is having cmpxchg{,64}_local actually worth it?
If you traverse the obfuscation chain a little, you'll find that local_cmpxchg() is implemented using cmpxchg_local(), and there are a few more users of that.
Quoted 3 lines · Ralf Baechle
How are the documentation files in
Documentation/features/maintained? They were automatically generated so I wonder if I have to take care of anything.
(Jon Cc:-ed)
Quoted 7 lines · Xose Vazquez Perez
Quoted 3 lines · Ralf Baechle
How are the documentation files in
Documentation/features/maintained? They were automatically generated so I wonder if I have to take care of anything.CC Ingo and related ml.
So changes to Documentation/features/ should come as simple patches done from hand editing, there's no need to preserve any initial (half-)automated generation. Formatting should be preserved so that Documentation/features/list-arch.sh still works as before.
Jon: would you like to receive all patches to Documentation/features/ so you can collect them in the documentation tree, or can maintainers patch it as part of any feature work that affects the tables? I think it's all finegrained enough to not create conflicts. That way they would become partly self-maintaining. (Or at least one can always hope! ;-)
Thanks,
Ingo
Quoted 5 lines · On Thu, 11 Jun 2015 08:24:53 +0200 Ingo Molnar <[email protected]> wrote:
Jon: would you like to receive all patches to
Documentation/features/so you can collect them in the documentation tree, or can maintainers patch it as part of any feature work that affects the tables? I think it's all finegrained enough to not create conflicts. That way they would become partly self-maintaining. (Or at least one can always hope! ;-)
I sort of figured I'd handle it the way I do the rest of Documentation/ — I'm happy to herd the patches, but I also have no problem staying out of the way when other maintainers reach into it.
jon