* Severe performance regression w/ 4.4+ on Android due to cgroup locking changes
@ 2016-07-13 0:00 John Stultz
2016-07-13 8:21 ` Peter Zijlstra
2016-07-13 18:21 ` Tejun Heo
0 siblings, 2 replies; 67+ messages in thread
From: John Stultz @ 2016-07-13 0:00 UTC (permalink / raw)
To: Tejun Heo
Cc: Ingo Molnar, Peter Zijlstra, lkml, Dmitry Shmidt, Rom Lemarchand,
Colin Cross, Todd Kjos
Hey Tejun,
So Dmitry Shmidt recently noticed that with 4.4 based systems we're
seeing quite a bit of performance overhead from
__cgroup_procs_write().
With 4.4 tree as it stands, we're seeing __cgroup_procs_write() quite
often take 10s of miliseconds to execute (with max times up in the
80ms range).
While with 4.1 it was quite often in the single usec range, and max
time values still in in sub-milisecond range.
The majority of these performance regressions seem to come from the
locking changes in:
3014dde762f6 ("cgroup: simplify threadgroup locking")
and
1ed1328792ff ("sched, cgroup: replace signal_struct->group_rwsem with
a global percpu_rwsem")
Dmitry has found that by reverting these two changes (which don't
revert easiliy), we can get back down to tens 10-100 usec range for
most calls, with max values occasionally spiking to ~18ms.
Those two commits do talk about performance regressions, that were
supposedly alleviated by percpu_rwsem changes, but I'm not sure we are
seeing this.
In 1ed1328792ff, the commit talks about the write path being a fairly
cold path, but with Android I worry this may not actually be the case,
as Android uses cpuset cgroups to group tasks into foreground and
background tasks, but this means when switching applications, tasks
are migrated between cgroups. Putting an additional 80 milisecond
delay on this adds potentially visible latencies on task switching.
Reverting those two changes in the Android common.git tree doesn't
feel like a good long term solution here, so I was wondering if you
had any thoughts on how to further reduce the performance regression
here?
All the credit for finding this goes to Dmitry, I just was able to
reproduce his results and thoguht we should bring it up for discussion
here.
thanks
-john
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 0:00 Severe performance regression w/ 4.4+ on Android due to cgroup locking changes John Stultz @ 2016-07-13 8:21 ` Peter Zijlstra 2016-07-13 14:42 ` Paul E. McKenney 2016-07-13 18:21 ` Tejun Heo 1 sibling, 1 reply; 67+ messages in thread From: Peter Zijlstra @ 2016-07-13 8:21 UTC (permalink / raw) To: John Stultz Cc: Tejun Heo, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov, Paul McKenney On Tue, Jul 12, 2016 at 05:00:04PM -0700, John Stultz wrote: > Hey Tejun, > > So Dmitry Shmidt recently noticed that with 4.4 based systems we're > seeing quite a bit of performance overhead from > __cgroup_procs_write(). > > With 4.4 tree as it stands, we're seeing __cgroup_procs_write() quite > often take 10s of miliseconds to execute (with max times up in the > 80ms range). > > While with 4.1 it was quite often in the single usec range, and max > time values still in in sub-milisecond range. > > The majority of these performance regressions seem to come from the > locking changes in: > > 3014dde762f6 ("cgroup: simplify threadgroup locking") > and > 1ed1328792ff ("sched, cgroup: replace signal_struct->group_rwsem with > a global percpu_rwsem") > > Dmitry has found that by reverting these two changes (which don't > revert easiliy), we can get back down to tens 10-100 usec range for > most calls, with max values occasionally spiking to ~18ms. > > Those two commits do talk about performance regressions, that were > supposedly alleviated by percpu_rwsem changes, but I'm not sure we are > seeing this. Do you have 'funny' RCU options that quickly force a grace period when you go idle or something? But yes, it does not surprise me to find this commit is causing problems. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 8:21 ` Peter Zijlstra @ 2016-07-13 14:42 ` Paul E. McKenney 2016-07-13 18:13 ` Dmitry Shmidt 0 siblings, 1 reply; 67+ messages in thread From: Paul E. McKenney @ 2016-07-13 14:42 UTC (permalink / raw) To: Peter Zijlstra Cc: John Stultz, Tejun Heo, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 10:21:12AM +0200, Peter Zijlstra wrote: > On Tue, Jul 12, 2016 at 05:00:04PM -0700, John Stultz wrote: > > Hey Tejun, > > > > So Dmitry Shmidt recently noticed that with 4.4 based systems we're > > seeing quite a bit of performance overhead from > > __cgroup_procs_write(). > > > > With 4.4 tree as it stands, we're seeing __cgroup_procs_write() quite > > often take 10s of miliseconds to execute (with max times up in the > > 80ms range). > > > > While with 4.1 it was quite often in the single usec range, and max > > time values still in in sub-milisecond range. > > > > The majority of these performance regressions seem to come from the > > locking changes in: > > > > 3014dde762f6 ("cgroup: simplify threadgroup locking") > > and > > 1ed1328792ff ("sched, cgroup: replace signal_struct->group_rwsem with > > a global percpu_rwsem") > > > > Dmitry has found that by reverting these two changes (which don't > > revert easiliy), we can get back down to tens 10-100 usec range for > > most calls, with max values occasionally spiking to ~18ms. > > > > Those two commits do talk about performance regressions, that were > > supposedly alleviated by percpu_rwsem changes, but I'm not sure we are > > seeing this. > > Do you have 'funny' RCU options that quickly force a grace period when > you go idle or something? > > But yes, it does not surprise me to find this commit is causing > problems. Hmmm... Looks like RCU is present both before and after. But please do send along your .config. Speaking of .config, is CONFIG_PREEMPT=y? If so, does the workload feature preemption and migration? If that is the case, you might be seeing contention on the per-CPU cgroup_threadgroup_rwsem, given that the second patch seems to be adding acquisitions. Thanx, Paul ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 14:42 ` Paul E. McKenney @ 2016-07-13 18:13 ` Dmitry Shmidt 2016-07-13 18:32 ` Paul E. McKenney 0 siblings, 1 reply; 67+ messages in thread From: Dmitry Shmidt @ 2016-07-13 18:13 UTC (permalink / raw) To: paulmck Cc: Peter Zijlstra, John Stultz, Tejun Heo, Ingo Molnar, lkml, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov [-- Attachment #1: Type: text/plain, Size: 2131 bytes --] On Wed, Jul 13, 2016 at 7:42 AM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > On Wed, Jul 13, 2016 at 10:21:12AM +0200, Peter Zijlstra wrote: >> On Tue, Jul 12, 2016 at 05:00:04PM -0700, John Stultz wrote: >> > Hey Tejun, >> > >> > So Dmitry Shmidt recently noticed that with 4.4 based systems we're >> > seeing quite a bit of performance overhead from >> > __cgroup_procs_write(). >> > >> > With 4.4 tree as it stands, we're seeing __cgroup_procs_write() quite >> > often take 10s of miliseconds to execute (with max times up in the >> > 80ms range). >> > >> > While with 4.1 it was quite often in the single usec range, and max >> > time values still in in sub-milisecond range. >> > >> > The majority of these performance regressions seem to come from the >> > locking changes in: >> > >> > 3014dde762f6 ("cgroup: simplify threadgroup locking") >> > and >> > 1ed1328792ff ("sched, cgroup: replace signal_struct->group_rwsem with >> > a global percpu_rwsem") >> > >> > Dmitry has found that by reverting these two changes (which don't >> > revert easiliy), we can get back down to tens 10-100 usec range for >> > most calls, with max values occasionally spiking to ~18ms. >> > >> > Those two commits do talk about performance regressions, that were >> > supposedly alleviated by percpu_rwsem changes, but I'm not sure we are >> > seeing this. >> >> Do you have 'funny' RCU options that quickly force a grace period when >> you go idle or something? >> >> But yes, it does not surprise me to find this commit is causing >> problems. > > Hmmm... Looks like RCU is present both before and after. But please > do send along your .config. Attached > Speaking of .config, is CONFIG_PREEMPT=y? If so, does the workload > feature preemption and migration? If that is the case, you might be > seeing contention on the per-CPU cgroup_threadgroup_rwsem, given that > the second patch seems to be adding acquisitions. CONFIG_PREEMPT=y is set. We see this issue during the boot, so it supposes to be enough CPU load to cause preemption and migration. > Thanx, Paul > [-- Attachment #2: .config --] [-- Type: application/octet-stream, Size: 118663 bytes --] # # Automatically generated file; DO NOT EDIT. # Linux/arm64 4.4.15 Kernel Configuration # CONFIG_ARM64=y CONFIG_64BIT=y CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_ARCH_MMAP_RND_BITS_MIN=18 CONFIG_ARCH_MMAP_RND_BITS_MAX=24 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000 CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CSUM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ZONE_DMA=y CONFIG_HAVE_GENERIC_RCU_GUP=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_SMP=y CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y CONFIG_KERNEL_MODE_NEON=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=3 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y # CONFIG_SYSVIPC is not set CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_SHOW_LEVEL=y CONFIG_GENERIC_IRQ_MIGRATION=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_HANDLE_DOMAIN_IRQ=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_ARCH_HAS_TICK_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_PREEMPT_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_EXPEDITE_BOOT is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_GENERIC_SCHED_CLOCK=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_PIDS is not set CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_CPUACCT=y CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y CONFIG_MEMCG_SWAP_ENABLED=y CONFIG_MEMCG_KMEM=y CONFIG_CGROUP_HUGETLB=y # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_CFS_BANDWIDTH is not set CONFIG_RT_GROUP_SCHED=y CONFIG_BLK_CGROUP=y # CONFIG_DEBUG_BLK_CGROUP is not set CONFIG_CGROUP_WRITEBACK=y # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_RD_LZ4=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_BPF=y CONFIG_EXPERT=y CONFIG_UID16=y CONFIG_MULTIUSER=y # CONFIG_SGETMASK_SYSCALL is not set CONFIG_SYSFS_SYSCALL=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y # CONFIG_BPF_SYSCALL is not set CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_ADVISE_SYSCALLS=y # CONFIG_USERFAULTFD is not set CONFIG_PCI_QUIRKS=y CONFIG_MEMBARRIER=y CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y # CONFIG_COMPAT_BRK is not set CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_SYSTEM_DATA_VERIFICATION is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_JUMP_LABEL=y # CONFIG_STATIC_KEYS_SELFTEST is not set # CONFIG_UPROBES is not set # CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_HAVE_DMA_CONTIGUOUS=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_GENERIC_IDLE_POLL_SETUP=y CONFIG_HAVE_CLK=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_HW_BREAKPOINT=y CONFIG_HAVE_PERF_REGS=y CONFIG_HAVE_PERF_USER_STACK_DUMP=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_HAVE_RCU_TABLE_FREE=y CONFIG_HAVE_CMPXCHG_LOCAL=y CONFIG_HAVE_CMPXCHG_DOUBLE=y CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y CONFIG_HAVE_ARCH_SECCOMP_FILTER=y CONFIG_SECCOMP_FILTER=y CONFIG_HAVE_CC_STACKPROTECTOR=y # CONFIG_CC_STACKPROTECTOR is not set CONFIG_CC_STACKPROTECTOR_NONE=y # CONFIG_CC_STACKPROTECTOR_REGULAR is not set # CONFIG_CC_STACKPROTECTOR_STRONG is not set CONFIG_HAVE_CONTEXT_TRACKING=y CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y CONFIG_MODULES_USE_ELF_RELA=y CONFIG_ARCH_HAS_ELF_RANDOMIZE=y CONFIG_HAVE_ARCH_MMAP_RND_BITS=y CONFIG_ARCH_MMAP_RND_BITS=18 CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS=y CONFIG_ARCH_MMAP_RND_COMPAT_BITS=11 CONFIG_CLONE_BACKWARDS=y CONFIG_OLD_SIGSUSPEND3=y CONFIG_COMPAT_OLD_SIGACTION=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_MODULES_TREE_LOOKUP=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_BSGLIB is not set # CONFIG_BLK_DEV_INTEGRITY is not set # CONFIG_BLK_DEV_THROTTLING is not set # CONFIG_BLK_CMDLINE_PARSER is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_EFI_PARTITION=y CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y CONFIG_CFQ_GROUP_IOSCHED=y CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_PREEMPT_NOTIFIERS=y CONFIG_UNINLINE_SPIN_UNLOCK=y CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y CONFIG_MUTEX_SPIN_ON_OWNER=y CONFIG_RWSEM_SPIN_ON_OWNER=y CONFIG_LOCK_SPIN_ON_OWNER=y CONFIG_FREEZER=y # # Platform selection # # CONFIG_ARCH_BCM_IPROC is not set # CONFIG_ARCH_BERLIN is not set # CONFIG_ARCH_EXYNOS7 is not set # CONFIG_ARCH_LAYERSCAPE is not set CONFIG_ARCH_HISI=y # CONFIG_ARCH_MEDIATEK is not set # CONFIG_ARCH_QCOM is not set # CONFIG_ARCH_ROCKCHIP is not set # CONFIG_ARCH_SEATTLE is not set # CONFIG_ARCH_STRATIX10 is not set # CONFIG_ARCH_TEGRA is not set # CONFIG_ARCH_SPRD is not set # CONFIG_ARCH_THUNDER is not set CONFIG_ARCH_VEXPRESS=y CONFIG_ARCH_XGENE=y # CONFIG_ARCH_ZYNQMP is not set # # Bus support # CONFIG_PCI=y CONFIG_PCI_DOMAINS=y CONFIG_PCI_DOMAINS_GENERIC=y CONFIG_PCI_SYSCALL=y CONFIG_PCI_BUS_ADDR_T_64BIT=y CONFIG_PCI_MSI=y CONFIG_PCI_MSI_IRQ_DOMAIN=y # CONFIG_PCI_DEBUG is not set # CONFIG_PCI_REALLOC_ENABLE_AUTO is not set # CONFIG_PCI_STUB is not set # CONFIG_PCI_IOV is not set # CONFIG_PCI_PRI is not set # CONFIG_PCI_PASID is not set CONFIG_PCI_LABEL=y # # PCI host controller drivers # # CONFIG_PCI_HOST_GENERIC is not set CONFIG_PCI_XGENE=y CONFIG_PCI_XGENE_MSI=y # CONFIG_PCIE_IPROC is not set # CONFIG_PCI_HISI is not set CONFIG_PCIEPORTBUS=y CONFIG_PCIEAER=y # CONFIG_PCIE_ECRC is not set # CONFIG_PCIEAER_INJECT is not set CONFIG_PCIEASPM=y # CONFIG_PCIEASPM_DEBUG is not set CONFIG_PCIEASPM_DEFAULT=y # CONFIG_PCIEASPM_POWERSAVE is not set # CONFIG_PCIEASPM_PERFORMANCE is not set CONFIG_PCIE_PME=y # CONFIG_HOTPLUG_PCI is not set # # Kernel Features # # # ARM errata workarounds via the alternatives framework # CONFIG_ARM64_ERRATUM_826319=y CONFIG_ARM64_ERRATUM_827319=y CONFIG_ARM64_ERRATUM_824069=y CONFIG_ARM64_ERRATUM_819472=y CONFIG_ARM64_ERRATUM_832075=y CONFIG_ARM64_ERRATUM_834220=y CONFIG_ARM64_ERRATUM_845719=y CONFIG_CAVIUM_ERRATUM_22375=y CONFIG_CAVIUM_ERRATUM_23154=y CONFIG_ARM64_4K_PAGES=y # CONFIG_ARM64_16K_PAGES is not set # CONFIG_ARM64_64K_PAGES is not set CONFIG_ARM64_VA_BITS_39=y # CONFIG_ARM64_VA_BITS_48 is not set CONFIG_ARM64_VA_BITS=39 # CONFIG_CPU_BIG_ENDIAN is not set CONFIG_SCHED_MC=y CONFIG_SCHED_SMT=y CONFIG_NR_CPUS=64 CONFIG_HOTPLUG_CPU=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_COUNT=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_SCHED_HRTICK=y CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_HAVE_ARCH_PFN_VALID=y CONFIG_HW_PERF_EVENTS=y CONFIG_SYS_SUPPORTS_HUGETLBFS=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_VMEMMAP=y CONFIG_HAVE_MEMBLOCK=y CONFIG_NO_BOOTMEM=y CONFIG_MEMORY_ISOLATION=y # CONFIG_HAVE_BOOTMEM_INFO_NODE is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_MEMORY_BALLOON=y CONFIG_BALLOON_COMPACTION=y CONFIG_COMPACTION=y CONFIG_MIGRATION=y CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_MMU_NOTIFIER=y CONFIG_KSM=y CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_TRANSPARENT_HUGEPAGE=y CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y # CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set # CONFIG_CLEANCACHE is not set # CONFIG_FRONTSWAP is not set CONFIG_CMA=y # CONFIG_CMA_DEBUG is not set # CONFIG_CMA_DEBUGFS is not set CONFIG_CMA_AREAS=7 # CONFIG_ZPOOL is not set # CONFIG_ZBUD is not set # CONFIG_ZSMALLOC is not set CONFIG_GENERIC_EARLY_IOREMAP=y # CONFIG_IDLE_PAGE_TRACKING is not set CONFIG_SECCOMP=y # CONFIG_XEN is not set CONFIG_FORCE_MAX_ZONEORDER=11 CONFIG_ARMV8_DEPRECATED=y CONFIG_SWP_EMULATION=y CONFIG_CP15_BARRIER_EMULATION=y CONFIG_SETEND_EMULATION=y # # ARMv8.1 architectural features # CONFIG_ARM64_HW_AFDBM=y CONFIG_ARM64_PAN=y # CONFIG_ARM64_LSE_ATOMICS is not set # # Boot options # CONFIG_CMDLINE="console=ttyAMA0" CONFIG_CMDLINE_FROM_BOOTLOADER=y # CONFIG_CMDLINE_EXTEND is not set # CONFIG_CMDLINE_FORCE is not set CONFIG_EFI_STUB=y CONFIG_EFI=y CONFIG_DMI=y CONFIG_BUILD_ARM64_APPENDED_DTB_IMAGE=y CONFIG_BUILD_ARM64_APPENDED_DTB_IMAGE_NAMES="hisilicon/hi6220-hikey" # # Userspace binary formats # CONFIG_BINFMT_ELF=y CONFIG_COMPAT_BINFMT_ELF=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set CONFIG_BINFMT_SCRIPT=y # CONFIG_HAVE_AOUT is not set CONFIG_BINFMT_MISC=y CONFIG_COREDUMP=y CONFIG_COMPAT=y # # Power management options # CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y # CONFIG_SUSPEND_SKIP_SYNC is not set CONFIG_WAKELOCK=y CONFIG_PM_SLEEP=y CONFIG_PM_SLEEP_SMP=y CONFIG_PM_AUTOSLEEP=y CONFIG_PM_WAKELOCKS=y CONFIG_PM_WAKELOCKS_LIMIT=100 CONFIG_PM_WAKELOCKS_GC=y CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_PM_OPP=y CONFIG_PM_CLK=y # CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set CONFIG_CPU_PM=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # # CPU Power Management # # # CPU Idle # CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y CONFIG_DT_IDLE_STATES=y # # ARM CPU Idle Drivers # CONFIG_ARM_CPUIDLE=y # CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_GOV_COMMON=y CONFIG_CPU_FREQ_STAT=y # CONFIG_CPU_FREQ_STAT_DETAILS is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_INTERACTIVE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_GOV_POWERSAVE is not set CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_INTERACTIVE=y # CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set # # CPU frequency scaling drivers # CONFIG_CPUFREQ_DT=y # CONFIG_ARM_BIG_LITTLE_CPUFREQ is not set CONFIG_ARM_HISI_ACPU_CPUFREQ=y # CONFIG_ARM_KIRKWOOD_CPUFREQ is not set # CONFIG_ACPI_CPPC_CPUFREQ is not set CONFIG_NET=y CONFIG_COMPAT_NETLINK_MESSAGES=y CONFIG_NET_INGRESS=y # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_DIAG is not set CONFIG_UNIX=y # CONFIG_UNIX_DIAG is not set CONFIG_XFRM=y CONFIG_XFRM_ALGO=y CONFIG_XFRM_USER=y # CONFIG_XFRM_SUB_POLICY is not set CONFIG_XFRM_MIGRATE=y # CONFIG_XFRM_STATISTICS is not set CONFIG_XFRM_IPCOMP=y CONFIG_NET_KEY=y CONFIG_NET_KEY_MIGRATE=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y # CONFIG_IP_FIB_TRIE_STATS is not set CONFIG_IP_MULTIPLE_TABLES=y # CONFIG_IP_ROUTE_MULTIPATH is not set # CONFIG_IP_ROUTE_VERBOSE is not set CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE_DEMUX is not set CONFIG_NET_IP_TUNNEL=y # CONFIG_IP_MROUTE is not set # CONFIG_SYN_COOKIES is not set # CONFIG_NET_IPVTI is not set # CONFIG_NET_UDP_TUNNEL is not set # CONFIG_NET_FOU is not set # CONFIG_NET_FOU_IP_TUNNELS is not set # CONFIG_INET_AH is not set CONFIG_INET_ESP=y # CONFIG_INET_IPCOMP is not set # CONFIG_INET_XFRM_TUNNEL is not set CONFIG_INET_TUNNEL=y CONFIG_INET_XFRM_MODE_TRANSPORT=y CONFIG_INET_XFRM_MODE_TUNNEL=y CONFIG_INET_XFRM_MODE_BEET=y # CONFIG_INET_LRO is not set CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y # CONFIG_INET_UDP_DIAG is not set CONFIG_INET_DIAG_DESTROY=y # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" # CONFIG_TCP_MD5SIG is not set CONFIG_IPV6=y CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_ROUTE_INFO=y CONFIG_IPV6_OPTIMISTIC_DAD=y CONFIG_INET6_AH=y CONFIG_INET6_ESP=y CONFIG_INET6_IPCOMP=y CONFIG_IPV6_MIP6=y # CONFIG_IPV6_ILA is not set CONFIG_INET6_XFRM_TUNNEL=y CONFIG_INET6_TUNNEL=y CONFIG_INET6_XFRM_MODE_TRANSPORT=y CONFIG_INET6_XFRM_MODE_TUNNEL=y CONFIG_INET6_XFRM_MODE_BEET=y # CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set # CONFIG_IPV6_VTI is not set CONFIG_IPV6_SIT=y # CONFIG_IPV6_SIT_6RD is not set CONFIG_IPV6_NDISC_NODETYPE=y # CONFIG_IPV6_TUNNEL is not set # CONFIG_IPV6_GRE is not set CONFIG_IPV6_MULTIPLE_TABLES=y # CONFIG_IPV6_SUBTREES is not set # CONFIG_IPV6_MROUTE is not set CONFIG_NETLABEL=y CONFIG_ANDROID_PARANOID_NETWORK=y CONFIG_NETWORK_SECMARK=y # CONFIG_NET_PTP_CLASSIFY is not set # CONFIG_NETWORK_PHY_TIMESTAMPING is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_NETFILTER_ADVANCED=y CONFIG_BRIDGE_NETFILTER=y # # Core Netfilter Configuration # CONFIG_NETFILTER_INGRESS=y CONFIG_NETFILTER_NETLINK=y # CONFIG_NETFILTER_NETLINK_ACCT is not set CONFIG_NETFILTER_NETLINK_QUEUE=y CONFIG_NETFILTER_NETLINK_LOG=y CONFIG_NF_CONNTRACK=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_PROCFS=y CONFIG_NF_CONNTRACK_EVENTS=y # CONFIG_NF_CONNTRACK_TIMEOUT is not set # CONFIG_NF_CONNTRACK_TIMESTAMP is not set CONFIG_NF_CT_PROTO_DCCP=y CONFIG_NF_CT_PROTO_GRE=y CONFIG_NF_CT_PROTO_SCTP=y CONFIG_NF_CT_PROTO_UDPLITE=y CONFIG_NF_CONNTRACK_AMANDA=y CONFIG_NF_CONNTRACK_FTP=y CONFIG_NF_CONNTRACK_H323=y CONFIG_NF_CONNTRACK_IRC=y CONFIG_NF_CONNTRACK_BROADCAST=y CONFIG_NF_CONNTRACK_NETBIOS_NS=y # CONFIG_NF_CONNTRACK_SNMP is not set CONFIG_NF_CONNTRACK_PPTP=y CONFIG_NF_CONNTRACK_SANE=y # CONFIG_NF_CONNTRACK_SIP is not set CONFIG_NF_CONNTRACK_TFTP=y CONFIG_NF_CT_NETLINK=y # CONFIG_NF_CT_NETLINK_TIMEOUT is not set # CONFIG_NETFILTER_NETLINK_GLUE_CT is not set CONFIG_NF_NAT=y CONFIG_NF_NAT_NEEDED=y CONFIG_NF_NAT_PROTO_DCCP=y CONFIG_NF_NAT_PROTO_UDPLITE=y CONFIG_NF_NAT_PROTO_SCTP=y CONFIG_NF_NAT_AMANDA=y CONFIG_NF_NAT_FTP=y CONFIG_NF_NAT_IRC=y # CONFIG_NF_NAT_SIP is not set CONFIG_NF_NAT_TFTP=y # CONFIG_NF_NAT_REDIRECT is not set # CONFIG_NF_TABLES is not set CONFIG_NETFILTER_XTABLES=y # # Xtables combined modules # CONFIG_NETFILTER_XT_MARK=y CONFIG_NETFILTER_XT_CONNMARK=y # # Xtables targets # # CONFIG_NETFILTER_XT_TARGET_AUDIT is not set # CONFIG_NETFILTER_XT_TARGET_CHECKSUM is not set CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y CONFIG_NETFILTER_XT_TARGET_CONNMARK=y CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=y # CONFIG_NETFILTER_XT_TARGET_CT is not set # CONFIG_NETFILTER_XT_TARGET_DSCP is not set # CONFIG_NETFILTER_XT_TARGET_HL is not set # CONFIG_NETFILTER_XT_TARGET_HMARK is not set CONFIG_NETFILTER_XT_TARGET_IDLETIMER=y # CONFIG_NETFILTER_XT_TARGET_LED is not set # CONFIG_NETFILTER_XT_TARGET_LOG is not set CONFIG_NETFILTER_XT_TARGET_MARK=y CONFIG_NETFILTER_XT_NAT=y # CONFIG_NETFILTER_XT_TARGET_NETMAP is not set CONFIG_NETFILTER_XT_TARGET_NFLOG=y CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y # CONFIG_NETFILTER_XT_TARGET_NOTRACK is not set # CONFIG_NETFILTER_XT_TARGET_RATEEST is not set # CONFIG_NETFILTER_XT_TARGET_REDIRECT is not set # CONFIG_NETFILTER_XT_TARGET_TEE is not set CONFIG_NETFILTER_XT_TARGET_TPROXY=y CONFIG_NETFILTER_XT_TARGET_TRACE=y CONFIG_NETFILTER_XT_TARGET_SECMARK=y CONFIG_NETFILTER_XT_TARGET_TCPMSS=y # CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP is not set # # Xtables matches # # CONFIG_NETFILTER_XT_MATCH_ADDRTYPE is not set # CONFIG_NETFILTER_XT_MATCH_BPF is not set # CONFIG_NETFILTER_XT_MATCH_CGROUP is not set # CONFIG_NETFILTER_XT_MATCH_CLUSTER is not set CONFIG_NETFILTER_XT_MATCH_COMMENT=y # CONFIG_NETFILTER_XT_MATCH_CONNBYTES is not set # CONFIG_NETFILTER_XT_MATCH_CONNLABEL is not set CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=y CONFIG_NETFILTER_XT_MATCH_CONNMARK=y CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y # CONFIG_NETFILTER_XT_MATCH_CPU is not set # CONFIG_NETFILTER_XT_MATCH_DCCP is not set # CONFIG_NETFILTER_XT_MATCH_DEVGROUP is not set # CONFIG_NETFILTER_XT_MATCH_DSCP is not set CONFIG_NETFILTER_XT_MATCH_ECN=y # CONFIG_NETFILTER_XT_MATCH_ESP is not set CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=y CONFIG_NETFILTER_XT_MATCH_HELPER=y CONFIG_NETFILTER_XT_MATCH_HL=y # CONFIG_NETFILTER_XT_MATCH_IPCOMP is not set CONFIG_NETFILTER_XT_MATCH_IPRANGE=y # CONFIG_NETFILTER_XT_MATCH_L2TP is not set CONFIG_NETFILTER_XT_MATCH_LENGTH=y CONFIG_NETFILTER_XT_MATCH_LIMIT=y CONFIG_NETFILTER_XT_MATCH_MAC=y CONFIG_NETFILTER_XT_MATCH_MARK=y # CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set # CONFIG_NETFILTER_XT_MATCH_NFACCT is not set # CONFIG_NETFILTER_XT_MATCH_OSF is not set # CONFIG_NETFILTER_XT_MATCH_OWNER is not set CONFIG_NETFILTER_XT_MATCH_POLICY=y # CONFIG_NETFILTER_XT_MATCH_PHYSDEV is not set CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y CONFIG_NETFILTER_XT_MATCH_QTAGUID=y CONFIG_NETFILTER_XT_MATCH_QUOTA=y CONFIG_NETFILTER_XT_MATCH_QUOTA2=y # CONFIG_NETFILTER_XT_MATCH_QUOTA2_LOG is not set # CONFIG_NETFILTER_XT_MATCH_RATEEST is not set # CONFIG_NETFILTER_XT_MATCH_REALM is not set # CONFIG_NETFILTER_XT_MATCH_RECENT is not set # CONFIG_NETFILTER_XT_MATCH_SCTP is not set CONFIG_NETFILTER_XT_MATCH_SOCKET=y CONFIG_NETFILTER_XT_MATCH_STATE=y CONFIG_NETFILTER_XT_MATCH_STATISTIC=y CONFIG_NETFILTER_XT_MATCH_STRING=y # CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set CONFIG_NETFILTER_XT_MATCH_TIME=y CONFIG_NETFILTER_XT_MATCH_U32=y # CONFIG_IP_SET is not set # CONFIG_IP_VS is not set # # IP: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV4=y CONFIG_NF_CONNTRACK_IPV4=y CONFIG_NF_CONNTRACK_PROC_COMPAT=y # CONFIG_NF_DUP_IPV4 is not set # CONFIG_NF_LOG_ARP is not set # CONFIG_NF_LOG_IPV4 is not set CONFIG_NF_REJECT_IPV4=y CONFIG_NF_NAT_IPV4=y CONFIG_NF_NAT_MASQUERADE_IPV4=y CONFIG_NF_NAT_PROTO_GRE=y CONFIG_NF_NAT_PPTP=y CONFIG_NF_NAT_H323=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_AH=y CONFIG_IP_NF_MATCH_ECN=y # CONFIG_IP_NF_MATCH_RPFILTER is not set CONFIG_IP_NF_MATCH_TTL=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y # CONFIG_IP_NF_TARGET_SYNPROXY is not set CONFIG_IP_NF_NAT=y CONFIG_IP_NF_TARGET_MASQUERADE=y # CONFIG_IP_NF_TARGET_NETMAP is not set # CONFIG_IP_NF_TARGET_REDIRECT is not set CONFIG_IP_NF_MANGLE=y # CONFIG_IP_NF_TARGET_CLUSTERIP is not set # CONFIG_IP_NF_TARGET_ECN is not set # CONFIG_IP_NF_TARGET_TTL is not set CONFIG_IP_NF_RAW=y CONFIG_IP_NF_SECURITY=y CONFIG_IP_NF_ARPTABLES=y CONFIG_IP_NF_ARPFILTER=y CONFIG_IP_NF_ARP_MANGLE=y # # IPv6: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV6=y CONFIG_NF_CONNTRACK_IPV6=y # CONFIG_NF_DUP_IPV6 is not set CONFIG_NF_REJECT_IPV6=y # CONFIG_NF_LOG_IPV6 is not set CONFIG_NF_NAT_IPV6=y CONFIG_NF_NAT_MASQUERADE_IPV6=y CONFIG_IP6_NF_IPTABLES=y CONFIG_IP6_NF_MATCH_AH=y CONFIG_IP6_NF_MATCH_EUI64=y CONFIG_IP6_NF_MATCH_FRAG=y CONFIG_IP6_NF_MATCH_OPTS=y CONFIG_IP6_NF_MATCH_HL=y CONFIG_IP6_NF_MATCH_IPV6HEADER=y CONFIG_IP6_NF_MATCH_MH=y # CONFIG_IP6_NF_MATCH_RPFILTER is not set # CONFIG_IP6_NF_MATCH_RT is not set # CONFIG_IP6_NF_TARGET_HL is not set CONFIG_IP6_NF_FILTER=y CONFIG_IP6_NF_TARGET_REJECT=y # CONFIG_IP6_NF_TARGET_SYNPROXY is not set CONFIG_IP6_NF_MANGLE=y CONFIG_IP6_NF_RAW=y # CONFIG_IP6_NF_SECURITY is not set CONFIG_IP6_NF_NAT=y CONFIG_IP6_NF_TARGET_MASQUERADE=y # CONFIG_IP6_NF_TARGET_NPT is not set # CONFIG_BRIDGE_NF_EBTABLES is not set # CONFIG_IP_DCCP is not set # CONFIG_IP_SCTP is not set # CONFIG_RDS is not set # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_L2TP is not set CONFIG_STP=y CONFIG_BRIDGE=y CONFIG_BRIDGE_IGMP_SNOOPING=y CONFIG_BRIDGE_VLAN_FILTERING=y CONFIG_HAVE_NET_DSA=y CONFIG_VLAN_8021Q=y # CONFIG_VLAN_8021Q_GVRP is not set # CONFIG_VLAN_8021Q_MVRP is not set # CONFIG_DECNET is not set CONFIG_LLC=y # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_PHONET is not set # CONFIG_6LOWPAN is not set # CONFIG_IEEE802154 is not set CONFIG_NET_SCHED=y # # Queueing/Scheduling # # CONFIG_NET_SCH_CBQ is not set CONFIG_NET_SCH_HTB=y # CONFIG_NET_SCH_HFSC is not set # CONFIG_NET_SCH_PRIO is not set # CONFIG_NET_SCH_MULTIQ is not set # CONFIG_NET_SCH_RED is not set # CONFIG_NET_SCH_SFB is not set # CONFIG_NET_SCH_SFQ is not set # CONFIG_NET_SCH_TEQL is not set # CONFIG_NET_SCH_TBF is not set # CONFIG_NET_SCH_GRED is not set # CONFIG_NET_SCH_DSMARK is not set # CONFIG_NET_SCH_NETEM is not set # CONFIG_NET_SCH_DRR is not set # CONFIG_NET_SCH_MQPRIO is not set # CONFIG_NET_SCH_CHOKE is not set # CONFIG_NET_SCH_QFQ is not set # CONFIG_NET_SCH_CODEL is not set # CONFIG_NET_SCH_FQ_CODEL is not set # CONFIG_NET_SCH_FQ is not set # CONFIG_NET_SCH_HHF is not set # CONFIG_NET_SCH_PIE is not set # CONFIG_NET_SCH_INGRESS is not set # CONFIG_NET_SCH_PLUG is not set # # Classification # CONFIG_NET_CLS=y # CONFIG_NET_CLS_BASIC is not set # CONFIG_NET_CLS_TCINDEX is not set # CONFIG_NET_CLS_ROUTE4 is not set # CONFIG_NET_CLS_FW is not set CONFIG_NET_CLS_U32=y # CONFIG_CLS_U32_PERF is not set # CONFIG_CLS_U32_MARK is not set # CONFIG_NET_CLS_RSVP is not set # CONFIG_NET_CLS_RSVP6 is not set # CONFIG_NET_CLS_FLOW is not set # CONFIG_NET_CLS_CGROUP is not set # CONFIG_NET_CLS_BPF is not set # CONFIG_NET_CLS_FLOWER is not set CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 # CONFIG_NET_EMATCH_CMP is not set # CONFIG_NET_EMATCH_NBYTE is not set CONFIG_NET_EMATCH_U32=y # CONFIG_NET_EMATCH_META is not set # CONFIG_NET_EMATCH_TEXT is not set CONFIG_NET_CLS_ACT=y # CONFIG_NET_ACT_POLICE is not set # CONFIG_NET_ACT_GACT is not set # CONFIG_NET_ACT_MIRRED is not set # CONFIG_NET_ACT_IPT is not set # CONFIG_NET_ACT_NAT is not set # CONFIG_NET_ACT_PEDIT is not set # CONFIG_NET_ACT_SIMP is not set # CONFIG_NET_ACT_SKBEDIT is not set # CONFIG_NET_ACT_CSUM is not set # CONFIG_NET_ACT_VLAN is not set # CONFIG_NET_ACT_BPF is not set # CONFIG_NET_ACT_CONNMARK is not set # CONFIG_NET_CLS_IND is not set CONFIG_NET_SCH_FIFO=y # CONFIG_DCB is not set CONFIG_DNS_RESOLVER=y # CONFIG_BATMAN_ADV is not set # CONFIG_OPENVSWITCH is not set # CONFIG_VSOCKETS is not set # CONFIG_NETLINK_MMAP is not set # CONFIG_NETLINK_DIAG is not set # CONFIG_MPLS is not set # CONFIG_HSR is not set # CONFIG_NET_SWITCHDEV is not set # CONFIG_NET_L3_MASTER_DEV is not set CONFIG_RPS=y CONFIG_RFS_ACCEL=y CONFIG_XPS=y # CONFIG_CGROUP_NET_PRIO is not set # CONFIG_CGROUP_NET_CLASSID is not set CONFIG_NET_RX_BUSY_POLL=y CONFIG_BQL=y CONFIG_NET_FLOW_LIMIT=y # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_NET_DROP_MONITOR is not set # CONFIG_HAMRADIO is not set # CONFIG_CAN is not set # CONFIG_IRDA is not set CONFIG_BT=y CONFIG_BT_BREDR=y CONFIG_BT_RFCOMM=y CONFIG_BT_RFCOMM_TTY=y # CONFIG_BT_BNEP is not set CONFIG_BT_HIDP=y CONFIG_BT_HS=y CONFIG_BT_LE=y # CONFIG_BT_SELFTEST is not set CONFIG_BT_DEBUGFS=y # # Bluetooth device drivers # # CONFIG_BT_HCIBTUSB is not set # CONFIG_BT_HCIBTSDIO is not set CONFIG_BT_HCIUART=y CONFIG_BT_HCIUART_H4=y # CONFIG_BT_HCIUART_BCSP is not set # CONFIG_BT_HCIUART_ATH3K is not set # CONFIG_BT_HCIUART_LL is not set # CONFIG_BT_HCIUART_3WIRE is not set # CONFIG_BT_HCIUART_INTEL is not set # CONFIG_BT_HCIUART_BCM is not set # CONFIG_BT_HCIUART_QCA is not set # CONFIG_BT_HCIBCM203X is not set # CONFIG_BT_HCIBPA10X is not set # CONFIG_BT_HCIBFUSB is not set # CONFIG_BT_HCIVHCI is not set # CONFIG_BT_MRVL is not set CONFIG_BT_WILINK=y # CONFIG_AF_RXRPC is not set CONFIG_FIB_RULES=y CONFIG_WIRELESS=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_CFG80211=y CONFIG_NL80211_TESTMODE=y # CONFIG_CFG80211_DEVELOPER_WARNINGS is not set CONFIG_CFG80211_REG_DEBUG=y # CONFIG_CFG80211_CERTIFICATION_ONUS is not set CONFIG_CFG80211_DEFAULT_PS=y # CONFIG_CFG80211_DEBUGFS is not set # CONFIG_CFG80211_INTERNAL_REGDB is not set CONFIG_CFG80211_CRDA_SUPPORT=y CONFIG_CFG80211_WEXT=y # CONFIG_LIB80211 is not set CONFIG_MAC80211=y CONFIG_MAC80211_HAS_RC=y CONFIG_MAC80211_RC_MINSTREL=y CONFIG_MAC80211_RC_MINSTREL_HT=y # CONFIG_MAC80211_RC_MINSTREL_VHT is not set CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT="minstrel_ht" CONFIG_MAC80211_MESH=y CONFIG_MAC80211_LEDS=y # CONFIG_MAC80211_DEBUGFS is not set # CONFIG_MAC80211_MESSAGE_TRACING is not set # CONFIG_MAC80211_DEBUG_MENU is not set CONFIG_MAC80211_STA_HASH_MAX_SIZE=0 # CONFIG_WIMAX is not set CONFIG_RFKILL=y CONFIG_RFKILL_PM=y CONFIG_RFKILL_LEDS=y # CONFIG_RFKILL_INPUT is not set CONFIG_RFKILL_REGULATOR=y CONFIG_RFKILL_GPIO=y CONFIG_NET_9P=y CONFIG_NET_9P_VIRTIO=y # CONFIG_NET_9P_DEBUG is not set # CONFIG_CAIF is not set # CONFIG_CEPH_LIB is not set # CONFIG_NFC is not set # CONFIG_LWTUNNEL is not set CONFIG_HAVE_BPF_JIT=y # # Device Drivers # CONFIG_ARM_AMBA=y # CONFIG_TEGRA_AHB is not set # # Generic Driver Options # CONFIG_UEVENT_HELPER=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" # CONFIG_DEVTMPFS is not set CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" CONFIG_FW_LOADER_USER_HELPER=y CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y CONFIG_ALLOW_DEV_COREDUMP=y # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_GENERIC_CPU_DEVICES is not set CONFIG_GENERIC_CPU_AUTOPROBE=y CONFIG_REGMAP=y CONFIG_REGMAP_I2C=y CONFIG_REGMAP_SPI=y CONFIG_REGMAP_MMIO=y CONFIG_REGMAP_IRQ=y CONFIG_DMA_SHARED_BUFFER=y # CONFIG_FENCE_TRACE is not set CONFIG_DMA_CMA=y # # Default contiguous memory area size: # CONFIG_CMA_SIZE_MBYTES=64 CONFIG_CMA_SIZE_SEL_MBYTES=y # CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set # CONFIG_CMA_SIZE_SEL_MIN is not set # CONFIG_CMA_SIZE_SEL_MAX is not set CONFIG_CMA_ALIGNMENT=8 # # Bus devices # # CONFIG_ARM_CCI400_PMU is not set # CONFIG_ARM_CCI500_PMU is not set # CONFIG_ARM_CCN is not set CONFIG_VEXPRESS_CONFIG=y CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y # CONFIG_MTD is not set CONFIG_DTC=y CONFIG_OF=y # CONFIG_OF_UNITTEST is not set CONFIG_OF_FLATTREE=y CONFIG_OF_EARLY_FLATTREE=y CONFIG_OF_DYNAMIC=y CONFIG_OF_ADDRESS=y CONFIG_OF_ADDRESS_PCI=y CONFIG_OF_IRQ=y CONFIG_OF_NET=y CONFIG_OF_MDIO=y CONFIG_OF_PCI=y CONFIG_OF_PCI_IRQ=y CONFIG_OF_RESERVED_MEM=y CONFIG_OF_RESOLVE=y CONFIG_OF_OVERLAY=y # CONFIG_PARPORT is not set CONFIG_PNP=y CONFIG_PNP_DEBUG_MESSAGES=y # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_NULL_BLK is not set # CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_DRBD is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SKD is not set # CONFIG_BLK_DEV_SX8 is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set CONFIG_VIRTIO_BLK=y # CONFIG_BLK_DEV_RBD is not set # CONFIG_BLK_DEV_RSXX is not set # CONFIG_BLK_DEV_NVME is not set # # Misc devices # # CONFIG_SENSORS_LIS3LV02D is not set # CONFIG_AD525X_DPOT is not set # CONFIG_DUMMY_IRQ is not set # CONFIG_PHANTOM is not set # CONFIG_SGI_IOC4 is not set # CONFIG_TIFM_CORE is not set # CONFIG_ICS932S401 is not set # CONFIG_ENCLOSURE_SERVICES is not set # CONFIG_HP_ILO is not set # CONFIG_APDS9802ALS is not set # CONFIG_ISL29003 is not set # CONFIG_ISL29020 is not set # CONFIG_SENSORS_TSL2550 is not set # CONFIG_SENSORS_BH1780 is not set # CONFIG_SENSORS_BH1770 is not set # CONFIG_SENSORS_APDS990X is not set # CONFIG_HMC6352 is not set # CONFIG_DS1682 is not set # CONFIG_TI_DAC7512 is not set # CONFIG_BMP085_I2C is not set # CONFIG_BMP085_SPI is not set CONFIG_HI6220_SYSCFG=y # CONFIG_USB_SWITCH_FSA9480 is not set # CONFIG_LATTICE_ECP3_CONFIG is not set # CONFIG_SRAM is not set CONFIG_VEXPRESS_SYSCFG=y CONFIG_UID_CPUTIME=y # CONFIG_C2PORT is not set # # EEPROM support # # CONFIG_EEPROM_AT24 is not set # CONFIG_EEPROM_AT25 is not set # CONFIG_EEPROM_LEGACY is not set # CONFIG_EEPROM_MAX6875 is not set # CONFIG_EEPROM_93CX6 is not set # CONFIG_EEPROM_93XX46 is not set # CONFIG_CB710_CORE is not set # # Texas Instruments shared transport line discipline # CONFIG_TI_ST=y CONFIG_ST_HCI=y # CONFIG_SENSORS_LIS3_I2C is not set # # Altera FPGA firmware download module # # CONFIG_ALTERA_STAPL is not set # # Intel MIC Bus Driver # # # SCIF Bus Driver # # # Intel MIC Host Driver # # # Intel MIC Card Driver # # # SCIF Driver # # # Intel MIC Coprocessor State Management (COSM) Drivers # # CONFIG_GENWQE is not set # CONFIG_ECHO is not set # CONFIG_CXL_BASE is not set # CONFIG_CXL_KERNEL_API is not set # CONFIG_CXL_EEH is not set # # SCSI device support # CONFIG_SCSI_MOD=y # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y # CONFIG_SCSI_NETLINK is not set # CONFIG_SCSI_MQ_DEFAULT is not set # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set # CONFIG_CHR_DEV_SCH is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SCAN_ASYNC is not set # # SCSI Transports # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SAS_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set # CONFIG_SCSI_SRP_ATTRS is not set # CONFIG_SCSI_LOWLEVEL is not set # CONFIG_SCSI_LOWLEVEL_PCMCIA is not set # CONFIG_SCSI_DH is not set # CONFIG_SCSI_OSD_INITIATOR is not set CONFIG_HAVE_PATA_PLATFORM=y CONFIG_ATA=y # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_VERBOSE_ERROR=y CONFIG_ATA_ACPI=y # CONFIG_SATA_ZPODD is not set CONFIG_SATA_PMP=y # # Controllers with non-SFF native interface # CONFIG_SATA_AHCI=y CONFIG_SATA_AHCI_PLATFORM=y # CONFIG_AHCI_CEVA is not set CONFIG_AHCI_XGENE=y # CONFIG_AHCI_QORIQ is not set # CONFIG_SATA_INIC162X is not set # CONFIG_SATA_ACARD_AHCI is not set # CONFIG_SATA_SIL24 is not set CONFIG_ATA_SFF=y # # SFF controllers with custom DMA interface # # CONFIG_PDC_ADMA is not set # CONFIG_SATA_QSTOR is not set # CONFIG_SATA_SX4 is not set CONFIG_ATA_BMDMA=y # # SATA SFF controllers with BMDMA # # CONFIG_ATA_PIIX is not set # CONFIG_SATA_MV is not set # CONFIG_SATA_NV is not set # CONFIG_SATA_PROMISE is not set # CONFIG_SATA_SIL is not set # CONFIG_SATA_SIS is not set # CONFIG_SATA_SVW is not set # CONFIG_SATA_ULI is not set # CONFIG_SATA_VIA is not set # CONFIG_SATA_VITESSE is not set # # PATA SFF controllers with BMDMA # # CONFIG_PATA_ALI is not set # CONFIG_PATA_AMD is not set # CONFIG_PATA_ARTOP is not set # CONFIG_PATA_ATIIXP is not set # CONFIG_PATA_ATP867X is not set # CONFIG_PATA_CMD64X is not set # CONFIG_PATA_CYPRESS is not set # CONFIG_PATA_EFAR is not set # CONFIG_PATA_HPT366 is not set # CONFIG_PATA_HPT37X is not set # CONFIG_PATA_HPT3X2N is not set # CONFIG_PATA_HPT3X3 is not set # CONFIG_PATA_IT8213 is not set # CONFIG_PATA_IT821X is not set # CONFIG_PATA_JMICRON is not set # CONFIG_PATA_MARVELL is not set # CONFIG_PATA_NETCELL is not set # CONFIG_PATA_NINJA32 is not set # CONFIG_PATA_NS87415 is not set # CONFIG_PATA_OLDPIIX is not set # CONFIG_PATA_OPTIDMA is not set # CONFIG_PATA_PDC2027X is not set # CONFIG_PATA_PDC_OLD is not set # CONFIG_PATA_RADISYS is not set # CONFIG_PATA_RDC is not set # CONFIG_PATA_SCH is not set # CONFIG_PATA_SERVERWORKS is not set # CONFIG_PATA_SIL680 is not set # CONFIG_PATA_SIS is not set # CONFIG_PATA_TOSHIBA is not set # CONFIG_PATA_TRIFLEX is not set # CONFIG_PATA_VIA is not set # CONFIG_PATA_WINBOND is not set # # PIO-only SFF controllers # # CONFIG_PATA_CMD640_PCI is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_OPTI is not set CONFIG_PATA_PLATFORM=y CONFIG_PATA_OF_PLATFORM=y # CONFIG_PATA_RZ1000 is not set # # Generic fallback / legacy drivers # # CONFIG_PATA_ACPI is not set # CONFIG_ATA_GENERIC is not set # CONFIG_PATA_LEGACY is not set CONFIG_MD=y # CONFIG_BLK_DEV_MD is not set # CONFIG_BCACHE is not set CONFIG_BLK_DEV_DM_BUILTIN=y CONFIG_BLK_DEV_DM=y # CONFIG_DM_MQ_DEFAULT is not set # CONFIG_DM_DEBUG is not set CONFIG_DM_BUFIO=y CONFIG_DM_CRYPT=y # CONFIG_DM_SNAPSHOT is not set # CONFIG_DM_THIN_PROVISIONING is not set # CONFIG_DM_CACHE is not set # CONFIG_DM_ERA is not set # CONFIG_DM_MIRROR is not set # CONFIG_DM_RAID is not set # CONFIG_DM_ZERO is not set # CONFIG_DM_MULTIPATH is not set # CONFIG_DM_DELAY is not set # CONFIG_DM_UEVENT is not set # CONFIG_DM_FLAKEY is not set CONFIG_DM_VERITY=y # CONFIG_DM_VERITY_FEC is not set # CONFIG_DM_SWITCH is not set # CONFIG_DM_LOG_WRITES is not set # CONFIG_TARGET_CORE is not set # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # # CONFIG_FIREWIRE is not set # CONFIG_FIREWIRE_NOSY is not set CONFIG_NETDEVICES=y CONFIG_MII=y CONFIG_NET_CORE=y # CONFIG_BONDING is not set # CONFIG_DUMMY is not set # CONFIG_EQUALIZER is not set # CONFIG_NET_FC is not set # CONFIG_IFB is not set # CONFIG_NET_TEAM is not set CONFIG_MACVLAN=y # CONFIG_MACVTAP is not set # CONFIG_IPVLAN is not set # CONFIG_VXLAN is not set # CONFIG_NETCONSOLE is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set CONFIG_TUN=y # CONFIG_TUN_VNET_CROSS_LE is not set CONFIG_VETH=y CONFIG_VIRTIO_NET=y # CONFIG_NLMON is not set # CONFIG_ARCNET is not set # # CAIF transport drivers # # CONFIG_VHOST_NET is not set # CONFIG_VHOST_CROSS_ENDIAN_LEGACY is not set # # Distributed Switch Architecture drivers # # CONFIG_NET_DSA_MV88E6XXX is not set # CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set CONFIG_ETHERNET=y CONFIG_NET_VENDOR_3COM=y # CONFIG_VORTEX is not set # CONFIG_TYPHOON is not set CONFIG_NET_VENDOR_ADAPTEC=y # CONFIG_ADAPTEC_STARFIRE is not set CONFIG_NET_VENDOR_AGERE=y # CONFIG_ET131X is not set CONFIG_NET_VENDOR_ALTEON=y # CONFIG_ACENIC is not set # CONFIG_ALTERA_TSE is not set CONFIG_NET_VENDOR_AMD=y # CONFIG_AMD8111_ETH is not set # CONFIG_PCNET32 is not set # CONFIG_AMD_XGBE is not set CONFIG_NET_XGENE=y CONFIG_NET_VENDOR_ARC=y # CONFIG_ARC_EMAC is not set # CONFIG_EMAC_ROCKCHIP is not set CONFIG_NET_VENDOR_ATHEROS=y # CONFIG_ATL2 is not set # CONFIG_ATL1 is not set # CONFIG_ATL1E is not set # CONFIG_ATL1C is not set # CONFIG_ALX is not set # CONFIG_NET_VENDOR_AURORA is not set CONFIG_NET_CADENCE=y # CONFIG_MACB is not set CONFIG_NET_VENDOR_BROADCOM=y # CONFIG_B44 is not set # CONFIG_BCMGENET is not set # CONFIG_BNX2 is not set # CONFIG_CNIC is not set # CONFIG_TIGON3 is not set # CONFIG_BNX2X is not set # CONFIG_SYSTEMPORT is not set # CONFIG_BNXT is not set CONFIG_NET_VENDOR_BROCADE=y # CONFIG_BNA is not set CONFIG_NET_VENDOR_CAVIUM=y # CONFIG_THUNDER_NIC_PF is not set # CONFIG_THUNDER_NIC_VF is not set # CONFIG_THUNDER_NIC_BGX is not set # CONFIG_LIQUIDIO is not set CONFIG_NET_VENDOR_CHELSIO=y # CONFIG_CHELSIO_T1 is not set # CONFIG_CHELSIO_T3 is not set # CONFIG_CHELSIO_T4 is not set # CONFIG_CHELSIO_T4VF is not set CONFIG_NET_VENDOR_CISCO=y # CONFIG_ENIC is not set # CONFIG_DNET is not set CONFIG_NET_VENDOR_DEC=y # CONFIG_NET_TULIP is not set CONFIG_NET_VENDOR_DLINK=y # CONFIG_DL2K is not set # CONFIG_SUNDANCE is not set CONFIG_NET_VENDOR_EMULEX=y # CONFIG_BE2NET is not set CONFIG_NET_VENDOR_EZCHIP=y # CONFIG_EZCHIP_NPS_MANAGEMENT_ENET is not set CONFIG_NET_VENDOR_EXAR=y # CONFIG_S2IO is not set # CONFIG_VXGE is not set CONFIG_NET_VENDOR_HISILICON=y # CONFIG_HIX5HD2_GMAC is not set # CONFIG_HIP04_ETH is not set # CONFIG_HNS is not set # CONFIG_HNS_DSAF is not set # CONFIG_HNS_ENET is not set CONFIG_NET_VENDOR_HP=y # CONFIG_HP100 is not set CONFIG_NET_VENDOR_INTEL=y # CONFIG_E100 is not set # CONFIG_E1000 is not set # CONFIG_E1000E is not set # CONFIG_IGB is not set # CONFIG_IGBVF is not set # CONFIG_IXGB is not set # CONFIG_IXGBE is not set # CONFIG_IXGBEVF is not set # CONFIG_I40E is not set # CONFIG_I40EVF is not set # CONFIG_FM10K is not set CONFIG_NET_VENDOR_I825XX=y # CONFIG_JME is not set CONFIG_NET_VENDOR_MARVELL=y # CONFIG_MVMDIO is not set # CONFIG_SKGE is not set # CONFIG_SKY2 is not set CONFIG_NET_VENDOR_MELLANOX=y # CONFIG_MLX4_EN is not set # CONFIG_MLX4_CORE is not set # CONFIG_MLX5_CORE is not set # CONFIG_MLXSW_CORE is not set CONFIG_NET_VENDOR_MICREL=y # CONFIG_KS8842 is not set # CONFIG_KS8851 is not set # CONFIG_KS8851_MLL is not set # CONFIG_KSZ884X_PCI is not set CONFIG_NET_VENDOR_MICROCHIP=y # CONFIG_ENC28J60 is not set # CONFIG_ENCX24J600 is not set CONFIG_NET_VENDOR_MYRI=y # CONFIG_MYRI10GE is not set # CONFIG_FEALNX is not set CONFIG_NET_VENDOR_NATSEMI=y # CONFIG_NATSEMI is not set # CONFIG_NS83820 is not set CONFIG_NET_VENDOR_8390=y # CONFIG_NE2K_PCI is not set CONFIG_NET_VENDOR_NVIDIA=y # CONFIG_FORCEDETH is not set CONFIG_NET_VENDOR_OKI=y # CONFIG_ETHOC is not set CONFIG_NET_PACKET_ENGINE=y # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set CONFIG_NET_VENDOR_QLOGIC=y # CONFIG_QLA3XXX is not set # CONFIG_QLCNIC is not set # CONFIG_QLGE is not set # CONFIG_NETXEN_NIC is not set # CONFIG_QED is not set CONFIG_NET_VENDOR_QUALCOMM=y # CONFIG_QCA7000 is not set CONFIG_NET_VENDOR_REALTEK=y # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_R8169 is not set CONFIG_NET_VENDOR_RENESAS=y CONFIG_NET_VENDOR_RDC=y # CONFIG_R6040 is not set CONFIG_NET_VENDOR_ROCKER=y CONFIG_NET_VENDOR_SAMSUNG=y # CONFIG_SXGBE_ETH is not set CONFIG_NET_VENDOR_SEEQ=y CONFIG_NET_VENDOR_SILAN=y # CONFIG_SC92031 is not set CONFIG_NET_VENDOR_SIS=y # CONFIG_SIS900 is not set # CONFIG_SIS190 is not set # CONFIG_SFC is not set CONFIG_NET_VENDOR_SMSC=y CONFIG_SMC91X=y # CONFIG_EPIC100 is not set CONFIG_SMSC911X=y # CONFIG_SMSC911X_ARCH_HOOKS is not set # CONFIG_SMSC9420 is not set CONFIG_NET_VENDOR_STMICRO=y # CONFIG_STMMAC_ETH is not set CONFIG_NET_VENDOR_SUN=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_CASSINI is not set # CONFIG_NIU is not set CONFIG_NET_VENDOR_SYNOPSYS=y # CONFIG_SYNOPSYS_DWC_ETH_QOS is not set CONFIG_NET_VENDOR_TEHUTI=y # CONFIG_TEHUTI is not set CONFIG_NET_VENDOR_TI=y # CONFIG_TI_CPSW_ALE is not set # CONFIG_TLAN is not set CONFIG_NET_VENDOR_VIA=y # CONFIG_VIA_RHINE is not set # CONFIG_VIA_VELOCITY is not set CONFIG_NET_VENDOR_WIZNET=y # CONFIG_WIZNET_W5100 is not set # CONFIG_WIZNET_W5300 is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_NET_SB1000 is not set CONFIG_PHYLIB=y # # MII PHY device drivers # # CONFIG_AQUANTIA_PHY is not set # CONFIG_AT803X_PHY is not set # CONFIG_AMD_PHY is not set # CONFIG_MARVELL_PHY is not set # CONFIG_DAVICOM_PHY is not set # CONFIG_QSEMI_PHY is not set # CONFIG_LXT_PHY is not set # CONFIG_CICADA_PHY is not set # CONFIG_VITESSE_PHY is not set # CONFIG_TERANETICS_PHY is not set # CONFIG_SMSC_PHY is not set # CONFIG_BROADCOM_PHY is not set # CONFIG_BCM7XXX_PHY is not set # CONFIG_BCM87XX_PHY is not set # CONFIG_ICPLUS_PHY is not set # CONFIG_REALTEK_PHY is not set # CONFIG_NATIONAL_PHY is not set # CONFIG_STE10XP is not set # CONFIG_LSI_ET1011C_PHY is not set # CONFIG_MICREL_PHY is not set # CONFIG_DP83848_PHY is not set # CONFIG_DP83867_PHY is not set # CONFIG_MICROCHIP_PHY is not set # CONFIG_FIXED_PHY is not set # CONFIG_MDIO_BITBANG is not set # CONFIG_MDIO_OCTEON is not set # CONFIG_MDIO_BUS_MUX_GPIO is not set # CONFIG_MDIO_BUS_MUX_MMIOREG is not set # CONFIG_MDIO_BCM_UNIMAC is not set # CONFIG_MICREL_KS8995MA is not set CONFIG_PPP=y CONFIG_PPP_BSDCOMP=y CONFIG_PPP_DEFLATE=y # CONFIG_PPP_FILTER is not set CONFIG_PPP_MPPE=y # CONFIG_PPP_MULTILINK is not set # CONFIG_PPPOE is not set # CONFIG_PPPOLAC is not set # CONFIG_PPPOPNS is not set # CONFIG_PPP_ASYNC is not set # CONFIG_PPP_SYNC_TTY is not set # CONFIG_SLIP is not set CONFIG_SLHC=y CONFIG_USB_NET_DRIVERS=y # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set CONFIG_USB_PEGASUS=y CONFIG_USB_RTL8150=y CONFIG_USB_RTL8152=y # CONFIG_USB_LAN78XX is not set CONFIG_USB_USBNET=y CONFIG_USB_NET_AX8817X=y CONFIG_USB_NET_AX88179_178A=y CONFIG_USB_NET_CDCETHER=y # CONFIG_USB_NET_CDC_EEM is not set CONFIG_USB_NET_CDC_NCM=y # CONFIG_USB_NET_HUAWEI_CDC_NCM is not set # CONFIG_USB_NET_CDC_MBIM is not set CONFIG_USB_NET_DM9601=y # CONFIG_USB_NET_SR9700 is not set CONFIG_USB_NET_SR9800=y CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y # CONFIG_USB_NET_GL620A is not set CONFIG_USB_NET_NET1080=y CONFIG_USB_NET_PLUSB=y CONFIG_USB_NET_MCS7830=y # CONFIG_USB_NET_RNDIS_HOST is not set CONFIG_USB_NET_CDC_SUBSET=y # CONFIG_USB_ALI_M5632 is not set # CONFIG_USB_AN2720 is not set CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y # CONFIG_USB_EPSON2888 is not set # CONFIG_USB_KC2190 is not set CONFIG_USB_NET_ZAURUS=y # CONFIG_USB_NET_CX82310_ETH is not set # CONFIG_USB_NET_KALMIA is not set # CONFIG_USB_NET_QMI_WWAN is not set # CONFIG_USB_HSO is not set # CONFIG_USB_NET_INT51X1 is not set # CONFIG_USB_IPHETH is not set # CONFIG_USB_SIERRA_NET is not set # CONFIG_USB_VL600 is not set # CONFIG_USB_NET_CH9200 is not set CONFIG_WLAN=y # CONFIG_LIBERTAS_THINFIRM is not set # CONFIG_ATMEL is not set # CONFIG_AT76C50X_USB is not set # CONFIG_PRISM54 is not set # CONFIG_USB_ZD1201 is not set # CONFIG_USB_NET_RNDIS_WLAN is not set # CONFIG_ADM8211 is not set # CONFIG_RTL8180 is not set # CONFIG_RTL8187 is not set # CONFIG_MAC80211_HWSIM is not set # CONFIG_MWL8K is not set # CONFIG_ATH_CARDS is not set # CONFIG_B43 is not set # CONFIG_B43LEGACY is not set # CONFIG_BRCMSMAC is not set # CONFIG_BRCMFMAC is not set # CONFIG_HOSTAP is not set # CONFIG_IPW2100 is not set # CONFIG_IPW2200 is not set # CONFIG_IWLWIFI is not set # CONFIG_IWL4965 is not set # CONFIG_IWL3945 is not set # CONFIG_LIBERTAS is not set # CONFIG_HERMES is not set # CONFIG_P54_COMMON is not set # CONFIG_RT2X00 is not set # CONFIG_WL_MEDIATEK is not set CONFIG_RTL_CARDS=y # CONFIG_RTL8192CE is not set # CONFIG_RTL8192SE is not set # CONFIG_RTL8192DE is not set # CONFIG_RTL8723AE is not set # CONFIG_RTL8723BE is not set # CONFIG_RTL8188EE is not set # CONFIG_RTL8192EE is not set # CONFIG_RTL8821AE is not set # CONFIG_RTL8192CU is not set # CONFIG_RTL8XXXU is not set CONFIG_WL_TI=y # CONFIG_WL1251 is not set # CONFIG_WL12XX is not set CONFIG_WL18XX=y CONFIG_WLCORE=y # CONFIG_WLCORE_SPI is not set CONFIG_WLCORE_SDIO=y CONFIG_WILINK_PLATFORM_DATA=y # CONFIG_ZD1211RW is not set # CONFIG_MWIFIEX is not set # CONFIG_CW1200 is not set # CONFIG_RSI_91X is not set # # Enable WiMAX (Networking options) to see the WiMAX drivers # # CONFIG_WAN is not set # CONFIG_VMXNET3 is not set # CONFIG_FUJITSU_ES is not set # CONFIG_ISDN is not set # CONFIG_NVM is not set # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_LEDS=y CONFIG_INPUT_FF_MEMLESS=y # CONFIG_INPUT_POLLDEV is not set # CONFIG_INPUT_SPARSEKMAP is not set # CONFIG_INPUT_MATRIXKMAP is not set # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # CONFIG_INPUT_KEYRESET is not set # CONFIG_INPUT_KEYCOMBO is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y # CONFIG_KEYBOARD_ADP5588 is not set # CONFIG_KEYBOARD_ADP5589 is not set CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_QT1070 is not set # CONFIG_KEYBOARD_QT2160 is not set # CONFIG_KEYBOARD_LKKBD is not set CONFIG_KEYBOARD_GPIO=y # CONFIG_KEYBOARD_GPIO_POLLED is not set # CONFIG_KEYBOARD_TCA6416 is not set # CONFIG_KEYBOARD_TCA8418 is not set # CONFIG_KEYBOARD_MATRIX is not set # CONFIG_KEYBOARD_LM8323 is not set # CONFIG_KEYBOARD_LM8333 is not set # CONFIG_KEYBOARD_MAX7359 is not set # CONFIG_KEYBOARD_MCS is not set # CONFIG_KEYBOARD_MPR121 is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_OPENCORES is not set # CONFIG_KEYBOARD_SAMSUNG is not set # CONFIG_KEYBOARD_STOWAWAY is not set # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_OMAP4 is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_CAP11XX is not set # CONFIG_KEYBOARD_BCM is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_CYPRESS=y CONFIG_MOUSE_PS2_TRACKPOINT=y # CONFIG_MOUSE_PS2_ELANTECH is not set # CONFIG_MOUSE_PS2_SENTELIC is not set # CONFIG_MOUSE_PS2_TOUCHKIT is not set CONFIG_MOUSE_PS2_FOCALTECH=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_BCM5974 is not set # CONFIG_MOUSE_CYAPA is not set # CONFIG_MOUSE_ELAN_I2C is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_MOUSE_GPIO is not set # CONFIG_MOUSE_SYNAPTICS_I2C is not set # CONFIG_MOUSE_SYNAPTICS_USB is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y # CONFIG_INPUT_AD714X is not set # CONFIG_INPUT_BMA150 is not set # CONFIG_INPUT_E3X0_BUTTON is not set # CONFIG_INPUT_MMA8450 is not set # CONFIG_INPUT_MPU3050 is not set # CONFIG_INPUT_GP2A is not set # CONFIG_INPUT_GPIO_BEEPER is not set # CONFIG_INPUT_GPIO_TILT_POLLED is not set # CONFIG_INPUT_ATI_REMOTE2 is not set # CONFIG_INPUT_KEYCHORD is not set # CONFIG_INPUT_KEYSPAN_REMOTE is not set # CONFIG_INPUT_KXTJ9 is not set # CONFIG_INPUT_POWERMATE is not set # CONFIG_INPUT_YEALINK is not set # CONFIG_INPUT_CM109 is not set # CONFIG_INPUT_REGULATOR_HAPTIC is not set CONFIG_INPUT_UINPUT=y # CONFIG_INPUT_GPIO is not set # CONFIG_INPUT_PCF8574 is not set # CONFIG_INPUT_GPIO_ROTARY_ENCODER is not set # CONFIG_INPUT_ADXL34X is not set # CONFIG_INPUT_IMS_PCU is not set # CONFIG_INPUT_CMA3000 is not set # CONFIG_INPUT_SOC_BUTTON_ARRAY is not set # CONFIG_INPUT_DRV260X_HAPTICS is not set # CONFIG_INPUT_DRV2665_HAPTICS is not set # CONFIG_INPUT_DRV2667_HAPTICS is not set CONFIG_HISI_POWERKEY=y # # Hardware I/O ports # CONFIG_SERIO=y # CONFIG_SERIO_SERPORT is not set CONFIG_SERIO_AMBAKMI=y # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_SERIO_ALTERA_PS2 is not set # CONFIG_SERIO_PS2MULT is not set # CONFIG_SERIO_ARC_PS2 is not set # CONFIG_SERIO_APBPS2 is not set # CONFIG_USERIO is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_TTY=y CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_VT_CONSOLE_SLEEP=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_UNIX98_PTYS=y CONFIG_DEVPTS_MULTIPLE_INSTANCES=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=16 # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_NOZOMI is not set # CONFIG_N_GSM is not set # CONFIG_TRACE_SINK is not set # CONFIG_DEVMEM is not set # CONFIG_DEVKMEM is not set # # Serial drivers # CONFIG_SERIAL_EARLYCON=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_DMA=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set CONFIG_SERIAL_8250_FSL=y # CONFIG_SERIAL_8250_DW is not set # CONFIG_SERIAL_8250_RT288X is not set # CONFIG_SERIAL_8250_FINTEK is not set # CONFIG_SERIAL_8250_INGENIC is not set # CONFIG_SERIAL_8250_MID is not set # # Non-8250 serial port support # # CONFIG_SERIAL_AMBA_PL010 is not set CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y # CONFIG_SERIAL_EARLYCON_ARM_SEMIHOST is not set # CONFIG_SERIAL_MAX3100 is not set # CONFIG_SERIAL_MAX310X is not set # CONFIG_SERIAL_UARTLITE is not set CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_JSM is not set CONFIG_SERIAL_OF_PLATFORM=y # CONFIG_SERIAL_SCCNXP is not set # CONFIG_SERIAL_SC16IS7XX is not set # CONFIG_SERIAL_ALTERA_JTAGUART is not set # CONFIG_SERIAL_ALTERA_UART is not set # CONFIG_SERIAL_IFX6X60 is not set # CONFIG_SERIAL_XILINX_PS_UART is not set # CONFIG_SERIAL_ARC is not set # CONFIG_SERIAL_RP2 is not set # CONFIG_SERIAL_FSL_LPUART is not set # CONFIG_SERIAL_CONEXANT_DIGICOLOR is not set # CONFIG_TTY_PRINTK is not set CONFIG_HVC_DRIVER=y # CONFIG_HVC_DCC is not set CONFIG_VIRTIO_CONSOLE=y # CONFIG_IPMI_HANDLER is not set # CONFIG_HW_RANDOM is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # PCMCIA character devices # # CONFIG_RAW_DRIVER is not set # CONFIG_HPET is not set # CONFIG_TCG_TPM is not set CONFIG_DEVPORT=y # CONFIG_XILLYBUS is not set # # I2C support # CONFIG_I2C=y CONFIG_ACPI_I2C_OPREGION=y CONFIG_I2C_BOARDINFO=y CONFIG_I2C_COMPAT=y CONFIG_I2C_CHARDEV=y # CONFIG_I2C_MUX is not set CONFIG_I2C_HELPER_AUTO=y CONFIG_I2C_ALGOBIT=y # # I2C Hardware Bus support # # # PC SMBus host controller drivers # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_ISCH is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # # ACPI drivers # # CONFIG_I2C_SCMI is not set # # I2C system bus drivers (mostly embedded / system-on-chip) # # CONFIG_I2C_CADENCE is not set # CONFIG_I2C_CBUS_GPIO is not set CONFIG_I2C_DESIGNWARE_CORE=y CONFIG_I2C_DESIGNWARE_PLATFORM=y # CONFIG_I2C_DESIGNWARE_PCI is not set # CONFIG_I2C_EMEV2 is not set # CONFIG_I2C_GPIO is not set # CONFIG_I2C_NOMADIK is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_PCA_PLATFORM is not set # CONFIG_I2C_PXA_PCI is not set # CONFIG_I2C_RK3X is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_I2C_VERSATILE is not set # CONFIG_I2C_XILINX is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_DIOLAN_U2C is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_ROBOTFUZZ_OSIF is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_TINY_USB is not set # # Other I2C/SMBus bus drivers # # CONFIG_I2C_XGENE_SLIMPRO is not set # CONFIG_I2C_SLAVE is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set CONFIG_SPI=y # CONFIG_SPI_DEBUG is not set CONFIG_SPI_MASTER=y # # SPI Master Controller Drivers # # CONFIG_SPI_ALTERA is not set # CONFIG_SPI_BITBANG is not set # CONFIG_SPI_CADENCE is not set # CONFIG_SPI_GPIO is not set # CONFIG_SPI_FSL_SPI is not set # CONFIG_SPI_OC_TINY is not set CONFIG_SPI_PL022=y # CONFIG_SPI_PXA2XX is not set # CONFIG_SPI_PXA2XX_PCI is not set # CONFIG_SPI_ROCKCHIP is not set # CONFIG_SPI_SC18IS602 is not set # CONFIG_SPI_XCOMM is not set # CONFIG_SPI_XILINX is not set # CONFIG_SPI_ZYNQMP_GQSPI is not set # CONFIG_SPI_DESIGNWARE is not set # # SPI Protocol Masters # # CONFIG_SPI_SPIDEV is not set # CONFIG_SPI_TLE62X0 is not set # CONFIG_SPMI is not set # CONFIG_HSI is not set # # PPS support # # CONFIG_PPS is not set # # PPS generators support # # # PTP clock support # # CONFIG_PTP_1588_CLOCK is not set # # Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks. # CONFIG_PINCTRL=y # # Pin controllers # CONFIG_PINMUX=y CONFIG_PINCONF=y CONFIG_GENERIC_PINCONF=y # CONFIG_DEBUG_PINCTRL is not set # CONFIG_PINCTRL_AMD is not set CONFIG_PINCTRL_SINGLE=y # CONFIG_PINCTRL_BAYTRAIL is not set # CONFIG_PINCTRL_CHERRYVIEW is not set # CONFIG_PINCTRL_BROXTON is not set # CONFIG_PINCTRL_SUNRISEPOINT is not set CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y CONFIG_ARCH_REQUIRE_GPIOLIB=y CONFIG_GPIOLIB=y CONFIG_GPIO_DEVRES=y CONFIG_OF_GPIO=y CONFIG_GPIO_ACPI=y CONFIG_GPIOLIB_IRQCHIP=y # CONFIG_DEBUG_GPIO is not set CONFIG_GPIO_SYSFS=y CONFIG_GPIO_GENERIC=y # # Memory mapped GPIO drivers # # CONFIG_GPIO_74XX_MMIO is not set # CONFIG_GPIO_ALTERA is not set # CONFIG_GPIO_AMDPT is not set # CONFIG_GPIO_DWAPB is not set CONFIG_GPIO_GENERIC_PLATFORM=y # CONFIG_GPIO_GRGPIO is not set CONFIG_GPIO_PL061=y # CONFIG_GPIO_SYSCON is not set # CONFIG_GPIO_VX855 is not set CONFIG_GPIO_XGENE=y # CONFIG_GPIO_XGENE_SB is not set # CONFIG_GPIO_XILINX is not set # CONFIG_GPIO_ZX is not set # # I2C GPIO expanders # # CONFIG_GPIO_ADP5588 is not set # CONFIG_GPIO_ADNP is not set # CONFIG_GPIO_MAX7300 is not set # CONFIG_GPIO_MAX732X is not set # CONFIG_GPIO_PCA953X is not set # CONFIG_GPIO_PCF857X is not set # CONFIG_GPIO_SX150X is not set # # MFD GPIO expanders # # # PCI GPIO expanders # # CONFIG_GPIO_AMD8111 is not set # CONFIG_GPIO_BT8XX is not set # CONFIG_GPIO_ML_IOH is not set # CONFIG_GPIO_RDC321X is not set # # SPI GPIO expanders # # CONFIG_GPIO_74X164 is not set # CONFIG_GPIO_MAX7301 is not set # CONFIG_GPIO_MC33880 is not set # # SPI or I2C GPIO expanders # # CONFIG_GPIO_MCP23S08 is not set # # USB GPIO expanders # # CONFIG_W1 is not set CONFIG_POWER_SUPPLY=y # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_TEST_POWER is not set # CONFIG_BATTERY_DS2780 is not set # CONFIG_BATTERY_DS2781 is not set # CONFIG_BATTERY_DS2782 is not set # CONFIG_BATTERY_SBS is not set # CONFIG_BATTERY_BQ27XXX is not set # CONFIG_BATTERY_MAX17040 is not set # CONFIG_BATTERY_MAX17042 is not set # CONFIG_CHARGER_MAX8903 is not set # CONFIG_CHARGER_LP8727 is not set # CONFIG_CHARGER_GPIO is not set # CONFIG_CHARGER_MANAGER is not set # CONFIG_CHARGER_BQ2415X is not set # CONFIG_CHARGER_BQ24190 is not set # CONFIG_CHARGER_BQ24257 is not set # CONFIG_CHARGER_BQ24735 is not set # CONFIG_CHARGER_BQ25890 is not set # CONFIG_CHARGER_SMB347 is not set # CONFIG_BATTERY_GAUGE_LTC2941 is not set # CONFIG_CHARGER_RT9455 is not set CONFIG_POWER_RESET=y # CONFIG_POWER_RESET_GPIO is not set # CONFIG_POWER_RESET_GPIO_RESTART is not set # CONFIG_POWER_RESET_HISI is not set # CONFIG_POWER_RESET_LTC2952 is not set # CONFIG_POWER_RESET_RESTART is not set CONFIG_POWER_RESET_VEXPRESS=y # CONFIG_POWER_RESET_XGENE is not set CONFIG_POWER_RESET_SYSCON=y # CONFIG_POWER_RESET_SYSCON_POWEROFF is not set # CONFIG_POWER_AVS is not set CONFIG_HWMON=y # CONFIG_HWMON_VID is not set # CONFIG_HWMON_DEBUG_CHIP is not set # # Native drivers # # CONFIG_SENSORS_AD7314 is not set # CONFIG_SENSORS_AD7414 is not set # CONFIG_SENSORS_AD7418 is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1029 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ADM9240 is not set # CONFIG_SENSORS_ADT7310 is not set # CONFIG_SENSORS_ADT7410 is not set # CONFIG_SENSORS_ADT7411 is not set # CONFIG_SENSORS_ADT7462 is not set # CONFIG_SENSORS_ADT7470 is not set # CONFIG_SENSORS_ADT7475 is not set # CONFIG_SENSORS_ASC7621 is not set # CONFIG_SENSORS_ATXP1 is not set # CONFIG_SENSORS_DS620 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_I5K_AMB is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_F71882FG is not set # CONFIG_SENSORS_F75375S is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set # CONFIG_SENSORS_G760A is not set # CONFIG_SENSORS_G762 is not set # CONFIG_SENSORS_GPIO_FAN is not set # CONFIG_SENSORS_HIH6130 is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_JC42 is not set # CONFIG_SENSORS_POWR1220 is not set # CONFIG_SENSORS_LINEAGE is not set # CONFIG_SENSORS_LTC2945 is not set # CONFIG_SENSORS_LTC4151 is not set # CONFIG_SENSORS_LTC4215 is not set # CONFIG_SENSORS_LTC4222 is not set # CONFIG_SENSORS_LTC4245 is not set # CONFIG_SENSORS_LTC4260 is not set # CONFIG_SENSORS_LTC4261 is not set # CONFIG_SENSORS_MAX1111 is not set # CONFIG_SENSORS_MAX16065 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_MAX1668 is not set # CONFIG_SENSORS_MAX197 is not set # CONFIG_SENSORS_MAX6639 is not set # CONFIG_SENSORS_MAX6642 is not set # CONFIG_SENSORS_MAX6650 is not set # CONFIG_SENSORS_MAX6697 is not set # CONFIG_SENSORS_MAX31790 is not set # CONFIG_SENSORS_HTU21 is not set # CONFIG_SENSORS_MCP3021 is not set # CONFIG_SENSORS_ADCXX is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM70 is not set # CONFIG_SENSORS_LM73 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_LM93 is not set # CONFIG_SENSORS_LM95234 is not set # CONFIG_SENSORS_LM95241 is not set # CONFIG_SENSORS_LM95245 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_PC87427 is not set # CONFIG_SENSORS_NTC_THERMISTOR is not set # CONFIG_SENSORS_NCT6683 is not set # CONFIG_SENSORS_NCT6775 is not set # CONFIG_SENSORS_NCT7802 is not set # CONFIG_SENSORS_NCT7904 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_PMBUS is not set # CONFIG_SENSORS_SHT15 is not set # CONFIG_SENSORS_SHT21 is not set # CONFIG_SENSORS_SHTC1 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_DME1737 is not set # CONFIG_SENSORS_EMC1403 is not set # CONFIG_SENSORS_EMC2103 is not set # CONFIG_SENSORS_EMC6W201 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47M192 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_SCH56XX_COMMON is not set # CONFIG_SENSORS_SMM665 is not set # CONFIG_SENSORS_ADC128D818 is not set # CONFIG_SENSORS_ADS1015 is not set # CONFIG_SENSORS_ADS7828 is not set # CONFIG_SENSORS_ADS7871 is not set # CONFIG_SENSORS_AMC6821 is not set # CONFIG_SENSORS_INA209 is not set # CONFIG_SENSORS_INA2XX is not set # CONFIG_SENSORS_TC74 is not set # CONFIG_SENSORS_THMC50 is not set # CONFIG_SENSORS_TMP102 is not set # CONFIG_SENSORS_TMP103 is not set # CONFIG_SENSORS_TMP401 is not set # CONFIG_SENSORS_TMP421 is not set # CONFIG_SENSORS_VEXPRESS is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_VT1211 is not set # CONFIG_SENSORS_VT8231 is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83791D is not set # CONFIG_SENSORS_W83792D is not set # CONFIG_SENSORS_W83793 is not set # CONFIG_SENSORS_W83795 is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83L786NG is not set # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83627EHF is not set # # ACPI drivers # # CONFIG_SENSORS_ACPI_POWER is not set CONFIG_THERMAL=y CONFIG_THERMAL_HWMON=y CONFIG_THERMAL_OF=y CONFIG_THERMAL_WRITABLE_TRIPS=y # CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE is not set # CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set # CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set CONFIG_THERMAL_DEFAULT_GOV_POWER_ALLOCATOR=y # CONFIG_THERMAL_GOV_FAIR_SHARE is not set CONFIG_THERMAL_GOV_STEP_WISE=y # CONFIG_THERMAL_GOV_BANG_BANG is not set CONFIG_THERMAL_GOV_USER_SPACE=y CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y CONFIG_CPU_THERMAL=y # CONFIG_CLOCK_THERMAL is not set # CONFIG_THERMAL_EMULATION is not set CONFIG_HISI_THERMAL=y # CONFIG_IMX_THERMAL is not set # CONFIG_WATCHDOG is not set CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # # CONFIG_SSB is not set CONFIG_BCMA_POSSIBLE=y # # Broadcom specific AMBA # # CONFIG_BCMA is not set # # Multifunction device drivers # CONFIG_MFD_CORE=y # CONFIG_MFD_AS3711 is not set # CONFIG_MFD_AS3722 is not set # CONFIG_PMIC_ADP5520 is not set # CONFIG_MFD_AAT2870_CORE is not set # CONFIG_MFD_ATMEL_FLEXCOM is not set # CONFIG_MFD_ATMEL_HLCDC is not set # CONFIG_MFD_BCM590XX is not set # CONFIG_MFD_AXP20X is not set # CONFIG_PMIC_DA903X is not set # CONFIG_MFD_DA9052_SPI is not set # CONFIG_MFD_DA9052_I2C is not set # CONFIG_MFD_DA9055 is not set # CONFIG_MFD_DA9062 is not set # CONFIG_MFD_DA9063 is not set # CONFIG_MFD_DA9150 is not set # CONFIG_MFD_DLN2 is not set # CONFIG_MFD_MC13XXX_SPI is not set # CONFIG_MFD_MC13XXX_I2C is not set # CONFIG_MFD_HI6421_PMIC is not set CONFIG_MFD_HI655X_PMIC=y # CONFIG_HTC_PASIC3 is not set # CONFIG_HTC_I2CPLD is not set # CONFIG_LPC_ICH is not set # CONFIG_LPC_SCH is not set # CONFIG_INTEL_SOC_PMIC is not set # CONFIG_MFD_JANZ_CMODIO is not set # CONFIG_MFD_KEMPLD is not set # CONFIG_MFD_88PM800 is not set # CONFIG_MFD_88PM805 is not set # CONFIG_MFD_88PM860X is not set # CONFIG_MFD_MAX14577 is not set # CONFIG_MFD_MAX77686 is not set # CONFIG_MFD_MAX77693 is not set # CONFIG_MFD_MAX77843 is not set # CONFIG_MFD_MAX8907 is not set # CONFIG_MFD_MAX8925 is not set # CONFIG_MFD_MAX8997 is not set # CONFIG_MFD_MAX8998 is not set # CONFIG_MFD_MT6397 is not set # CONFIG_MFD_MENF21BMC is not set # CONFIG_EZX_PCAP is not set # CONFIG_MFD_VIPERBOARD is not set # CONFIG_MFD_RETU is not set # CONFIG_MFD_PCF50633 is not set # CONFIG_MFD_RDC321X is not set # CONFIG_MFD_RTSX_PCI is not set # CONFIG_MFD_RT5033 is not set # CONFIG_MFD_RTSX_USB is not set # CONFIG_MFD_RC5T583 is not set # CONFIG_MFD_RK808 is not set # CONFIG_MFD_RN5T618 is not set # CONFIG_MFD_SEC_CORE is not set # CONFIG_MFD_SI476X_CORE is not set # CONFIG_MFD_SM501 is not set # CONFIG_MFD_SKY81452 is not set # CONFIG_MFD_SMSC is not set # CONFIG_ABX500_CORE is not set # CONFIG_MFD_STMPE is not set CONFIG_MFD_SYSCON=y # CONFIG_MFD_TI_AM335X_TSCADC is not set # CONFIG_MFD_LP3943 is not set # CONFIG_MFD_LP8788 is not set # CONFIG_MFD_PALMAS is not set # CONFIG_TPS6105X is not set # CONFIG_TPS65010 is not set # CONFIG_TPS6507X is not set # CONFIG_MFD_TPS65090 is not set # CONFIG_MFD_TPS65217 is not set # CONFIG_MFD_TPS65218 is not set # CONFIG_MFD_TPS6586X is not set # CONFIG_MFD_TPS65910 is not set # CONFIG_MFD_TPS65912 is not set # CONFIG_MFD_TPS65912_I2C is not set # CONFIG_MFD_TPS65912_SPI is not set # CONFIG_MFD_TPS80031 is not set # CONFIG_TWL4030_CORE is not set # CONFIG_TWL6040_CORE is not set # CONFIG_MFD_WL1273_CORE is not set # CONFIG_MFD_LM3533 is not set # CONFIG_MFD_TC3589X is not set # CONFIG_MFD_TMIO is not set # CONFIG_MFD_VX855 is not set # CONFIG_MFD_ARIZONA_I2C is not set # CONFIG_MFD_ARIZONA_SPI is not set # CONFIG_MFD_WM8400 is not set # CONFIG_MFD_WM831X_I2C is not set # CONFIG_MFD_WM831X_SPI is not set # CONFIG_MFD_WM8350_I2C is not set # CONFIG_MFD_WM8994 is not set CONFIG_MFD_VEXPRESS_SYSREG=y CONFIG_REGULATOR=y # CONFIG_REGULATOR_DEBUG is not set CONFIG_REGULATOR_FIXED_VOLTAGE=y # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_USERSPACE_CONSUMER is not set # CONFIG_REGULATOR_ACT8865 is not set # CONFIG_REGULATOR_AD5398 is not set # CONFIG_REGULATOR_ANATOP is not set # CONFIG_REGULATOR_DA9210 is not set # CONFIG_REGULATOR_DA9211 is not set # CONFIG_REGULATOR_FAN53555 is not set # CONFIG_REGULATOR_GPIO is not set CONFIG_REGULATOR_HI6220_MTCMOS=y CONFIG_REGULATOR_HI655X=y # CONFIG_REGULATOR_ISL9305 is not set # CONFIG_REGULATOR_ISL6271A is not set # CONFIG_REGULATOR_LP3971 is not set # CONFIG_REGULATOR_LP3972 is not set # CONFIG_REGULATOR_LP872X is not set # CONFIG_REGULATOR_LP8755 is not set # CONFIG_REGULATOR_LTC3589 is not set # CONFIG_REGULATOR_MAX1586 is not set # CONFIG_REGULATOR_MAX8649 is not set # CONFIG_REGULATOR_MAX8660 is not set # CONFIG_REGULATOR_MAX8952 is not set # CONFIG_REGULATOR_MAX8973 is not set # CONFIG_REGULATOR_MT6311 is not set # CONFIG_REGULATOR_PFUZE100 is not set # CONFIG_REGULATOR_TPS51632 is not set # CONFIG_REGULATOR_TPS62360 is not set # CONFIG_REGULATOR_TPS65023 is not set # CONFIG_REGULATOR_TPS6507X is not set # CONFIG_REGULATOR_TPS6524X is not set # CONFIG_REGULATOR_VEXPRESS is not set CONFIG_MEDIA_SUPPORT=y # # Multimedia core support # # CONFIG_MEDIA_CAMERA_SUPPORT is not set CONFIG_MEDIA_ANALOG_TV_SUPPORT=y # CONFIG_MEDIA_DIGITAL_TV_SUPPORT is not set # CONFIG_MEDIA_RADIO_SUPPORT is not set # CONFIG_MEDIA_SDR_SUPPORT is not set # CONFIG_MEDIA_RC_SUPPORT is not set # CONFIG_MEDIA_CONTROLLER is not set CONFIG_VIDEO_DEV=y CONFIG_VIDEO_V4L2=y # CONFIG_VIDEO_ADV_DEBUG is not set # CONFIG_VIDEO_FIXED_MINOR_RANGES is not set # CONFIG_TTPCI_EEPROM is not set # # Media drivers # # CONFIG_MEDIA_USB_SUPPORT is not set # CONFIG_MEDIA_PCI_SUPPORT is not set # # Supported MMC/SDIO adapters # # CONFIG_CYPRESS_FIRMWARE is not set # # Media ancillary drivers (tuners, sensors, i2c, frontends) # # CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set # # Encoders, decoders, sensors and other helper chips # # # Audio decoders, processors and mixers # # CONFIG_VIDEO_TVAUDIO is not set # CONFIG_VIDEO_TDA7432 is not set # CONFIG_VIDEO_TDA9840 is not set # CONFIG_VIDEO_TEA6415C is not set # CONFIG_VIDEO_TEA6420 is not set # CONFIG_VIDEO_MSP3400 is not set # CONFIG_VIDEO_CS5345 is not set # CONFIG_VIDEO_CS53L32A is not set # CONFIG_VIDEO_TLV320AIC23B is not set # CONFIG_VIDEO_UDA1342 is not set # CONFIG_VIDEO_WM8775 is not set # CONFIG_VIDEO_WM8739 is not set # CONFIG_VIDEO_VP27SMPX is not set # CONFIG_VIDEO_SONY_BTF_MPX is not set # # RDS decoders # # CONFIG_VIDEO_SAA6588 is not set # # Video decoders # # CONFIG_VIDEO_ADV7183 is not set # CONFIG_VIDEO_BT819 is not set # CONFIG_VIDEO_BT856 is not set # CONFIG_VIDEO_BT866 is not set # CONFIG_VIDEO_KS0127 is not set # CONFIG_VIDEO_ML86V7667 is not set # CONFIG_VIDEO_SAA7110 is not set # CONFIG_VIDEO_SAA711X is not set # CONFIG_VIDEO_TVP514X is not set # CONFIG_VIDEO_TVP5150 is not set # CONFIG_VIDEO_TVP7002 is not set # CONFIG_VIDEO_TW2804 is not set # CONFIG_VIDEO_TW9903 is not set # CONFIG_VIDEO_TW9906 is not set # CONFIG_VIDEO_VPX3220 is not set # # Video and audio decoders # # CONFIG_VIDEO_SAA717X is not set # CONFIG_VIDEO_CX25840 is not set # # Video encoders # # CONFIG_VIDEO_SAA7127 is not set # CONFIG_VIDEO_SAA7185 is not set # CONFIG_VIDEO_ADV7170 is not set # CONFIG_VIDEO_ADV7175 is not set # CONFIG_VIDEO_ADV7343 is not set # CONFIG_VIDEO_ADV7393 is not set # CONFIG_VIDEO_AK881X is not set # CONFIG_VIDEO_THS8200 is not set # # Camera sensor devices # # # Flash devices # # # Video improvement chips # # CONFIG_VIDEO_UPD64031A is not set # CONFIG_VIDEO_UPD64083 is not set # # Audio/Video compression chips # # CONFIG_VIDEO_SAA6752HS is not set # # Miscellaneous helper chips # # CONFIG_VIDEO_THS7303 is not set # CONFIG_VIDEO_M52790 is not set # # Sensors used on soc_camera driver # CONFIG_MEDIA_TUNER=y # # Customize TV tuners # CONFIG_MEDIA_TUNER_SIMPLE=y CONFIG_MEDIA_TUNER_TDA8290=y CONFIG_MEDIA_TUNER_TDA827X=y CONFIG_MEDIA_TUNER_TDA18271=y CONFIG_MEDIA_TUNER_TDA9887=y CONFIG_MEDIA_TUNER_TEA5761=y CONFIG_MEDIA_TUNER_TEA5767=y CONFIG_MEDIA_TUNER_MSI001=y CONFIG_MEDIA_TUNER_MT20XX=y CONFIG_MEDIA_TUNER_MT2060=y CONFIG_MEDIA_TUNER_MT2063=y CONFIG_MEDIA_TUNER_MT2266=y CONFIG_MEDIA_TUNER_MT2131=y CONFIG_MEDIA_TUNER_QT1010=y CONFIG_MEDIA_TUNER_XC2028=y CONFIG_MEDIA_TUNER_XC5000=y CONFIG_MEDIA_TUNER_XC4000=y CONFIG_MEDIA_TUNER_MXL5005S=y CONFIG_MEDIA_TUNER_MXL5007T=y CONFIG_MEDIA_TUNER_MC44S803=y CONFIG_MEDIA_TUNER_MAX2165=y CONFIG_MEDIA_TUNER_TDA18218=y CONFIG_MEDIA_TUNER_FC0011=y CONFIG_MEDIA_TUNER_FC0012=y CONFIG_MEDIA_TUNER_FC0013=y CONFIG_MEDIA_TUNER_TDA18212=y CONFIG_MEDIA_TUNER_E4000=y CONFIG_MEDIA_TUNER_FC2580=y CONFIG_MEDIA_TUNER_M88RS6000T=y CONFIG_MEDIA_TUNER_TUA9001=y CONFIG_MEDIA_TUNER_SI2157=y CONFIG_MEDIA_TUNER_IT913X=y CONFIG_MEDIA_TUNER_R820T=y CONFIG_MEDIA_TUNER_MXL301RF=y CONFIG_MEDIA_TUNER_QM1D1C0042=y # # Customise DVB Frontends # CONFIG_DVB_AU8522=y CONFIG_DVB_AU8522_V4L=y CONFIG_DVB_TUNER_DIB0070=y CONFIG_DVB_TUNER_DIB0090=y # # Tools to develop new frontends # # CONFIG_DVB_DUMMY_FE is not set # # Graphics support # CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=16 CONFIG_MALI400=y CONFIG_MALI450=y # CONFIG_MALI470 is not set CONFIG_MALI400_DEBUG=y # CONFIG_MALI400_PROFILING is not set # CONFIG_MALI400_UMP is not set # CONFIG_MALI_DVFS is not set CONFIG_MALI_DMA_BUF_MAP_ON_ATTACH=y CONFIG_MALI_SHARED_INTERRUPTS=y # CONFIG_MALI_PMU_PARALLEL_POWER_UP is not set CONFIG_MALI_DT=y CONFIG_MALI_PLAT_SPECIFIC_DT=y CONFIG_DRM=y CONFIG_DRM_MIPI_DSI=y CONFIG_DRM_KMS_HELPER=y CONFIG_DRM_KMS_FB_HELPER=y CONFIG_DRM_FBDEV_EMULATION=y # CONFIG_DRM_LOAD_EDID_FIRMWARE is not set CONFIG_DRM_GEM_CMA_HELPER=y CONFIG_DRM_KMS_CMA_HELPER=y CONFIG_DRM_CMA_FBDEV_BUFFER_NUM=2 # # I2C encoder or helper chips # CONFIG_DRM_I2C_ADV7511=y # CONFIG_DRM_I2C_CH7006 is not set # CONFIG_DRM_I2C_SIL164 is not set # CONFIG_DRM_I2C_NXP_TDA998X is not set # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_AMDGPU is not set # CONFIG_DRM_NOUVEAU is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set # CONFIG_DRM_VGEM is not set # CONFIG_DRM_UDL is not set # CONFIG_DRM_AST is not set # CONFIG_DRM_MGAG200 is not set # CONFIG_DRM_CIRRUS_QEMU is not set # CONFIG_DRM_QXL is not set # CONFIG_DRM_BOCHS is not set # CONFIG_DRM_VIRTIO_GPU is not set CONFIG_DRM_PANEL=y # # Display Panels # # CONFIG_DRM_PANEL_SIMPLE is not set # CONFIG_DRM_PANEL_SAMSUNG_LD9040 is not set # CONFIG_DRM_PANEL_LG_LG4573 is not set # CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0 is not set # CONFIG_DRM_PANEL_SHARP_LQ101R1SX01 is not set CONFIG_DRM_PANEL_HIKEY=y CONFIG_DRM_BRIDGE=y # # Display Interface Bridges # # CONFIG_DRM_NXP_PTN3460 is not set # CONFIG_DRM_PARADE_PS8622 is not set CONFIG_DRM_HISI_KIRIN=y CONFIG_HISI_KIRIN_DW_DSI=y # # Frame buffer Devices # CONFIG_FB=y # CONFIG_FIRMWARE_EDID is not set CONFIG_FB_CMDLINE=y # CONFIG_FB_DDC is not set # CONFIG_FB_BOOT_VESA_SUPPORT is not set CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=y CONFIG_FB_SYS_COPYAREA=y CONFIG_FB_SYS_IMAGEBLIT=y # CONFIG_FB_FOREIGN_ENDIAN is not set CONFIG_FB_SYS_FOPS=y # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set CONFIG_FB_MODE_HELPERS=y # CONFIG_FB_TILEBLITTING is not set # # Frame buffer hardware drivers # # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set CONFIG_FB_ARMCLCD=y # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_UVESA is not set # CONFIG_FB_OPENCORES is not set # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_NVIDIA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_I740 is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_S3 is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_VT8623 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_ARK is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_CARMINE is not set # CONFIG_FB_SMSCUFX is not set # CONFIG_FB_UDL is not set # CONFIG_FB_IBM_GXT4500 is not set # CONFIG_FB_VIRTUAL is not set # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set # CONFIG_FB_BROADSHEET is not set # CONFIG_FB_AUO_K190X is not set CONFIG_FB_SIMPLE=y # CONFIG_FB_SSD1307 is not set # CONFIG_FB_SM712 is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y # CONFIG_LCD_L4F00242T03 is not set # CONFIG_LCD_LMS283GF05 is not set # CONFIG_LCD_LTV350QV is not set # CONFIG_LCD_ILI922X is not set # CONFIG_LCD_ILI9320 is not set # CONFIG_LCD_TDO24M is not set # CONFIG_LCD_VGG2432A4 is not set # CONFIG_LCD_PLATFORM is not set # CONFIG_LCD_S6E63M0 is not set # CONFIG_LCD_LD9040 is not set # CONFIG_LCD_AMS369FG06 is not set # CONFIG_LCD_LMS501KF03 is not set # CONFIG_LCD_HX8357 is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_BACKLIGHT_GENERIC=y # CONFIG_BACKLIGHT_PM8941_WLED is not set # CONFIG_BACKLIGHT_ADP8860 is not set # CONFIG_BACKLIGHT_ADP8870 is not set # CONFIG_BACKLIGHT_LM3639 is not set # CONFIG_BACKLIGHT_GPIO is not set # CONFIG_BACKLIGHT_LV5207LP is not set # CONFIG_BACKLIGHT_BD6107 is not set # CONFIG_ADF is not set # CONFIG_VGASTATE is not set CONFIG_VIDEOMODE_HELPERS=y CONFIG_HDMI=y # # Console display driver support # CONFIG_DUMMY_CONSOLE=y CONFIG_DUMMY_CONSOLE_COLUMNS=80 CONFIG_DUMMY_CONSOLE_ROWS=25 # CONFIG_FRAMEBUFFER_CONSOLE is not set # CONFIG_LOGO is not set CONFIG_SOUND=y # CONFIG_SOUND_OSS_CORE is not set CONFIG_SND=y CONFIG_SND_TIMER=y CONFIG_SND_PCM=y CONFIG_SND_DMAENGINE_PCM=y CONFIG_SND_HWDEP=y CONFIG_SND_RAWMIDI=y CONFIG_SND_JACK=y # CONFIG_SND_SEQUENCER is not set # CONFIG_SND_MIXER_OSS is not set # CONFIG_SND_PCM_OSS is not set CONFIG_SND_PCM_TIMER=y # CONFIG_SND_HRTIMER is not set # CONFIG_SND_DYNAMIC_MINORS is not set CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SND_PROC_FS=y CONFIG_SND_VERBOSE_PROCFS=y CONFIG_SND_VERBOSE_PRINTK=y CONFIG_SND_DEBUG=y CONFIG_SND_DEBUG_VERBOSE=y # CONFIG_SND_PCM_XRUN_DEBUG is not set # CONFIG_SND_RAWMIDI_SEQ is not set # CONFIG_SND_OPL3_LIB_SEQ is not set # CONFIG_SND_OPL4_LIB_SEQ is not set # CONFIG_SND_SBAWE_SEQ is not set # CONFIG_SND_EMU10K1_SEQ is not set CONFIG_SND_DRIVERS=y # CONFIG_SND_DUMMY is not set # CONFIG_SND_ALOOP is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set # CONFIG_SND_MPU401 is not set CONFIG_SND_PCI=y # CONFIG_SND_AD1889 is not set # CONFIG_SND_ALS300 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AW2 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_OXYGEN is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CTXFI is not set # CONFIG_SND_DARLA20 is not set # CONFIG_SND_GINA20 is not set # CONFIG_SND_LAYLA20 is not set # CONFIG_SND_DARLA24 is not set # CONFIG_SND_GINA24 is not set # CONFIG_SND_LAYLA24 is not set # CONFIG_SND_MONA is not set # CONFIG_SND_MIA is not set # CONFIG_SND_ECHO3G is not set # CONFIG_SND_INDIGO is not set # CONFIG_SND_INDIGOIO is not set # CONFIG_SND_INDIGODJ is not set # CONFIG_SND_INDIGOIOX is not set # CONFIG_SND_INDIGODJX is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_HDSPM is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_LOLA is not set # CONFIG_SND_LX6464ES is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_PCXHR is not set # CONFIG_SND_RIPTIDE is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_SE6X is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VIRTUOSO is not set # CONFIG_SND_VX222 is not set # CONFIG_SND_YMFPCI is not set # # HD-Audio # # CONFIG_SND_HDA_INTEL is not set CONFIG_SND_HDA_PREALLOC_SIZE=64 CONFIG_SND_SPI=y CONFIG_SND_USB=y CONFIG_SND_USB_AUDIO=y # CONFIG_SND_USB_UA101 is not set # CONFIG_SND_USB_CAIAQ is not set # CONFIG_SND_USB_6FIRE is not set # CONFIG_SND_USB_HIFACE is not set # CONFIG_SND_BCD2000 is not set # CONFIG_SND_USB_POD is not set # CONFIG_SND_USB_PODHD is not set # CONFIG_SND_USB_TONEPORT is not set # CONFIG_SND_USB_VARIAX is not set CONFIG_SND_SOC=y CONFIG_SND_SOC_GENERIC_DMAENGINE_PCM=y # CONFIG_SND_ATMEL_SOC is not set # CONFIG_SND_DESIGNWARE_I2S is not set # # SoC Audio for Freescale CPUs # # # Common SoC Audio options for Freescale CPUs: # # CONFIG_SND_SOC_FSL_ASRC is not set # CONFIG_SND_SOC_FSL_SAI is not set # CONFIG_SND_SOC_FSL_SSI is not set # CONFIG_SND_SOC_FSL_SPDIF is not set # CONFIG_SND_SOC_FSL_ESAI is not set # CONFIG_SND_SOC_IMX_AUDMUX is not set CONFIG_SND_I2S_HI6210_I2S=y # # Allwinner SoC Audio support # # CONFIG_SND_SUN4I_CODEC is not set # CONFIG_SND_SOC_XTFPGA_I2S is not set CONFIG_SND_SOC_I2C_AND_SPI=y # # CODEC drivers # # CONFIG_SND_SOC_AC97_CODEC is not set # CONFIG_SND_SOC_ADAU1701 is not set # CONFIG_SND_SOC_AK4104 is not set # CONFIG_SND_SOC_AK4554 is not set # CONFIG_SND_SOC_AK4613 is not set # CONFIG_SND_SOC_AK4642 is not set # CONFIG_SND_SOC_AK5386 is not set # CONFIG_SND_SOC_ALC5623 is not set # CONFIG_SND_SOC_CS35L32 is not set # CONFIG_SND_SOC_CS42L51_I2C is not set # CONFIG_SND_SOC_CS42L52 is not set # CONFIG_SND_SOC_CS42L56 is not set # CONFIG_SND_SOC_CS42L73 is not set # CONFIG_SND_SOC_CS4265 is not set # CONFIG_SND_SOC_CS4270 is not set # CONFIG_SND_SOC_CS4271_I2C is not set # CONFIG_SND_SOC_CS4271_SPI is not set # CONFIG_SND_SOC_CS42XX8_I2C is not set # CONFIG_SND_SOC_CS4349 is not set # CONFIG_SND_SOC_ES8328 is not set # CONFIG_SND_SOC_GTM601 is not set # CONFIG_SND_SOC_PCM1681 is not set # CONFIG_SND_SOC_PCM1792A is not set # CONFIG_SND_SOC_PCM512x_I2C is not set # CONFIG_SND_SOC_PCM512x_SPI is not set # CONFIG_SND_SOC_RT5631 is not set # CONFIG_SND_SOC_RT5677_SPI is not set # CONFIG_SND_SOC_SGTL5000 is not set # CONFIG_SND_SOC_SIRF_AUDIO_CODEC is not set # CONFIG_SND_SOC_SPDIF is not set # CONFIG_SND_SOC_SSM2602_SPI is not set # CONFIG_SND_SOC_SSM2602_I2C is not set # CONFIG_SND_SOC_SSM4567 is not set # CONFIG_SND_SOC_STA32X is not set # CONFIG_SND_SOC_STA350 is not set # CONFIG_SND_SOC_STI_SAS is not set # CONFIG_SND_SOC_TAS2552 is not set # CONFIG_SND_SOC_TAS5086 is not set # CONFIG_SND_SOC_TAS571X is not set # CONFIG_SND_SOC_TFA9879 is not set # CONFIG_SND_SOC_TLV320AIC23_I2C is not set # CONFIG_SND_SOC_TLV320AIC23_SPI is not set # CONFIG_SND_SOC_TLV320AIC31XX is not set # CONFIG_SND_SOC_TLV320AIC3X is not set # CONFIG_SND_SOC_TS3A227E is not set # CONFIG_SND_SOC_WM8510 is not set # CONFIG_SND_SOC_WM8523 is not set # CONFIG_SND_SOC_WM8580 is not set # CONFIG_SND_SOC_WM8711 is not set # CONFIG_SND_SOC_WM8728 is not set # CONFIG_SND_SOC_WM8731 is not set # CONFIG_SND_SOC_WM8737 is not set # CONFIG_SND_SOC_WM8741 is not set # CONFIG_SND_SOC_WM8750 is not set # CONFIG_SND_SOC_WM8753 is not set # CONFIG_SND_SOC_WM8770 is not set # CONFIG_SND_SOC_WM8776 is not set # CONFIG_SND_SOC_WM8804_I2C is not set # CONFIG_SND_SOC_WM8804_SPI is not set # CONFIG_SND_SOC_WM8903 is not set # CONFIG_SND_SOC_WM8962 is not set # CONFIG_SND_SOC_WM8978 is not set # CONFIG_SND_SOC_TPA6130A2 is not set # CONFIG_SND_SIMPLE_CARD is not set # CONFIG_SOUND_PRIME is not set # # HID support # CONFIG_HID=y # CONFIG_HID_BATTERY_STRENGTH is not set CONFIG_HIDRAW=y CONFIG_UHID=y CONFIG_HID_GENERIC=y # # Special HID drivers # CONFIG_HID_A4TECH=y CONFIG_HID_ACRUX=y CONFIG_HID_ACRUX_FF=y CONFIG_HID_APPLE=y # CONFIG_HID_APPLEIR is not set # CONFIG_HID_AUREAL is not set CONFIG_HID_BELKIN=y # CONFIG_HID_BETOP_FF is not set CONFIG_HID_CHERRY=y CONFIG_HID_CHICONY=y # CONFIG_HID_CORSAIR is not set CONFIG_HID_PRODIKEYS=y # CONFIG_HID_CP2112 is not set CONFIG_HID_CYPRESS=y CONFIG_HID_DRAGONRISE=y CONFIG_DRAGONRISE_FF=y CONFIG_HID_EMS_FF=y CONFIG_HID_ELECOM=y # CONFIG_HID_ELO is not set CONFIG_HID_EZKEY=y # CONFIG_HID_GEMBIRD is not set # CONFIG_HID_GFRM is not set # CONFIG_HID_HOLTEK is not set # CONFIG_HID_GT683R is not set CONFIG_HID_KEYTOUCH=y CONFIG_HID_KYE=y # CONFIG_HID_UCLOGIC is not set CONFIG_HID_WALTOP=y CONFIG_HID_GYRATION=y # CONFIG_HID_ICADE is not set CONFIG_HID_TWINHAN=y CONFIG_HID_KENSINGTON=y CONFIG_HID_LCPOWER=y # CONFIG_HID_LENOVO is not set CONFIG_HID_LOGITECH=y CONFIG_HID_LOGITECH_DJ=y CONFIG_HID_LOGITECH_HIDPP=y CONFIG_LOGITECH_FF=y CONFIG_LOGIRUMBLEPAD2_FF=y CONFIG_LOGIG940_FF=y CONFIG_LOGIWHEELS_FF=y CONFIG_HID_MAGICMOUSE=y CONFIG_HID_MICROSOFT=y CONFIG_HID_MONTEREY=y CONFIG_HID_MULTITOUCH=y # CONFIG_HID_NTRIG is not set CONFIG_HID_ORTEK=y CONFIG_HID_PANTHERLORD=y CONFIG_PANTHERLORD_FF=y # CONFIG_HID_PENMOUNT is not set CONFIG_HID_PETALYNX=y CONFIG_HID_PICOLCD=y # CONFIG_HID_PICOLCD_FB is not set # CONFIG_HID_PICOLCD_BACKLIGHT is not set # CONFIG_HID_PICOLCD_LCD is not set # CONFIG_HID_PICOLCD_LEDS is not set # CONFIG_HID_PLANTRONICS is not set CONFIG_HID_PRIMAX=y # CONFIG_HID_ROCCAT is not set CONFIG_HID_SAITEK=y CONFIG_HID_SAMSUNG=y # CONFIG_HID_SONY is not set CONFIG_HID_SPEEDLINK=y # CONFIG_HID_STEELSERIES is not set CONFIG_HID_SUNPLUS=y # CONFIG_HID_RMI is not set CONFIG_HID_GREENASIA=y CONFIG_GREENASIA_FF=y CONFIG_HID_SMARTJOYPLUS=y CONFIG_SMARTJOYPLUS_FF=y CONFIG_HID_TIVO=y CONFIG_HID_TOPSEED=y # CONFIG_HID_THINGM is not set CONFIG_HID_THRUSTMASTER=y # CONFIG_THRUSTMASTER_FF is not set CONFIG_HID_WACOM=y CONFIG_HID_WIIMOTE=y # CONFIG_HID_XINMO is not set CONFIG_HID_ZEROPLUS=y # CONFIG_ZEROPLUS_FF is not set CONFIG_HID_ZYDACRON=y # CONFIG_HID_SENSOR_HUB is not set # # USB HID support # CONFIG_USB_HID=y # CONFIG_HID_PID is not set # CONFIG_USB_HIDDEV is not set # # I2C HID support # # CONFIG_I2C_HID is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_SUPPORT=y CONFIG_USB_COMMON=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB=y # CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set # # Miscellaneous USB options # CONFIG_USB_DEFAULT_PERSIST=y # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_OTG is not set # CONFIG_USB_OTG_WHITELIST is not set # CONFIG_USB_OTG_BLACKLIST_HUB is not set # CONFIG_USB_ULPI_BUS is not set # CONFIG_USB_MON is not set # CONFIG_USB_WUSB_CBAF is not set # # USB Host Controller Drivers # # CONFIG_USB_C67X00_HCD is not set # CONFIG_USB_XHCI_HCD is not set CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_ROOT_HUB_TT is not set CONFIG_USB_EHCI_TT_NEWSCHED=y CONFIG_USB_EHCI_PCI=y CONFIG_USB_EHCI_HCD_PLATFORM=y # CONFIG_USB_OXU210HP_HCD is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1362_HCD is not set # CONFIG_USB_FOTG210_HCD is not set # CONFIG_USB_MAX3421_HCD is not set CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_HCD_PCI=y CONFIG_USB_OHCI_HCD_PLATFORM=y # CONFIG_USB_UHCI_HCD is not set # CONFIG_USB_SL811_HCD is not set # CONFIG_USB_R8A66597_HCD is not set # CONFIG_USB_HCD_TEST_MODE is not set # # USB Device Class drivers # CONFIG_USB_ACM=y # CONFIG_USB_PRINTER is not set # CONFIG_USB_WDM is not set # CONFIG_USB_TMC is not set # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may # # # also be needed; see USB_STORAGE Help for more info # CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_REALTEK is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set # CONFIG_USB_STORAGE_ENE_UB6250 is not set # CONFIG_USB_UAS is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USBIP_CORE is not set # CONFIG_USB_MUSB_HDRC is not set # CONFIG_USB_DWC3 is not set CONFIG_USB_DWC2=y # CONFIG_USB_DWC2_HOST is not set # # Gadget/Dual-role mode requires USB Gadget support to be enabled # # CONFIG_USB_DWC2_PERIPHERAL is not set CONFIG_USB_DWC2_DUAL_ROLE=y # CONFIG_USB_DWC2_PCI is not set # CONFIG_USB_DWC2_DEBUG is not set # CONFIG_USB_DWC2_TRACK_MISSED_SOFS is not set # CONFIG_USB_CHIPIDEA is not set # CONFIG_USB_ISP1760 is not set # # USB port drivers # CONFIG_USB_SERIAL=y # CONFIG_USB_SERIAL_CONSOLE is not set CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_SIMPLE=y # CONFIG_USB_SERIAL_AIRCABLE is not set # CONFIG_USB_SERIAL_ARK3116 is not set # CONFIG_USB_SERIAL_BELKIN is not set # CONFIG_USB_SERIAL_CH341 is not set # CONFIG_USB_SERIAL_WHITEHEAT is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_CP210X is not set # CONFIG_USB_SERIAL_CYPRESS_M8 is not set # CONFIG_USB_SERIAL_EMPEG is not set CONFIG_USB_SERIAL_FTDI_SIO=y # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IPAQ is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_EDGEPORT_TI is not set # CONFIG_USB_SERIAL_F81232 is not set # CONFIG_USB_SERIAL_GARMIN is not set # CONFIG_USB_SERIAL_IPW is not set # CONFIG_USB_SERIAL_IUU is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KLSI is not set # CONFIG_USB_SERIAL_KOBIL_SCT is not set # CONFIG_USB_SERIAL_MCT_U232 is not set # CONFIG_USB_SERIAL_METRO is not set # CONFIG_USB_SERIAL_MOS7720 is not set # CONFIG_USB_SERIAL_MOS7840 is not set # CONFIG_USB_SERIAL_MXUPORT is not set # CONFIG_USB_SERIAL_NAVMAN is not set CONFIG_USB_SERIAL_PL2303=y # CONFIG_USB_SERIAL_OTI6858 is not set # CONFIG_USB_SERIAL_QCAUX is not set CONFIG_USB_SERIAL_QUALCOMM=y # CONFIG_USB_SERIAL_SPCP8X5 is not set # CONFIG_USB_SERIAL_SAFE is not set # CONFIG_USB_SERIAL_SIERRAWIRELESS is not set # CONFIG_USB_SERIAL_SYMBOL is not set # CONFIG_USB_SERIAL_TI is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set CONFIG_USB_SERIAL_WWAN=y CONFIG_USB_SERIAL_OPTION=y # CONFIG_USB_SERIAL_OMNINET is not set # CONFIG_USB_SERIAL_OPTICON is not set # CONFIG_USB_SERIAL_XSENS_MT is not set # CONFIG_USB_SERIAL_WISHBONE is not set # CONFIG_USB_SERIAL_SSU100 is not set # CONFIG_USB_SERIAL_QT2 is not set # CONFIG_USB_SERIAL_DEBUG is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_SEVSEG is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # CONFIG_USB_EHSET_TEST_FIXTURE is not set # CONFIG_USB_ISIGHTFW is not set # CONFIG_USB_YUREX is not set # CONFIG_USB_EZUSB_FX2 is not set # CONFIG_USB_HSIC_USB3503 is not set # CONFIG_USB_LINK_LAYER_TEST is not set # # USB Physical Layer drivers # # CONFIG_USB_PHY is not set CONFIG_USB_OTG_WAKELOCK=y # CONFIG_NOP_USB_XCEIV is not set # CONFIG_USB_GPIO_VBUS is not set # CONFIG_USB_ISP1301 is not set CONFIG_USB_ULPI=y CONFIG_USB_ULPI_VIEWPORT=y CONFIG_USB_GADGET=y # CONFIG_USB_GADGET_DEBUG is not set # CONFIG_USB_GADGET_DEBUG_FILES is not set # CONFIG_USB_GADGET_DEBUG_FS is not set CONFIG_USB_GADGET_VBUS_DRAW=2 CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2 # # USB Peripheral Controller # # CONFIG_USB_FOTG210_UDC is not set # CONFIG_USB_GR_UDC is not set # CONFIG_USB_R8A66597 is not set # CONFIG_USB_PXA27X is not set # CONFIG_USB_MV_UDC is not set # CONFIG_USB_MV_U3D is not set # CONFIG_USB_M66592 is not set # CONFIG_USB_BDC_UDC is not set # CONFIG_USB_AMD5536UDC is not set # CONFIG_USB_NET2272 is not set # CONFIG_USB_NET2280 is not set # CONFIG_USB_GOKU is not set # CONFIG_USB_EG20T is not set # CONFIG_USB_GADGET_XILINX is not set # CONFIG_USB_DUMMY_HCD is not set CONFIG_USB_LIBCOMPOSITE=y CONFIG_USB_F_ACM=y CONFIG_USB_U_SERIAL=y CONFIG_USB_U_ETHER=y CONFIG_USB_F_SERIAL=y CONFIG_USB_F_RNDIS=y CONFIG_USB_F_FS=y CONFIG_USB_F_MIDI=y CONFIG_USB_F_MTP=y CONFIG_USB_F_PTP=y CONFIG_USB_F_AUDIO_SRC=y CONFIG_USB_F_ACC=y CONFIG_USB_CONFIGFS=y CONFIG_USB_CONFIGFS_SERIAL=y CONFIG_USB_CONFIGFS_ACM=y # CONFIG_USB_CONFIGFS_OBEX is not set # CONFIG_USB_CONFIGFS_NCM is not set # CONFIG_USB_CONFIGFS_ECM is not set # CONFIG_USB_CONFIGFS_ECM_SUBSET is not set CONFIG_USB_CONFIGFS_RNDIS=y # CONFIG_USB_CONFIGFS_EEM is not set # CONFIG_USB_CONFIGFS_MASS_STORAGE is not set # CONFIG_USB_CONFIGFS_F_LB_SS is not set CONFIG_USB_CONFIGFS_F_FS=y CONFIG_USB_CONFIGFS_F_MTP=y CONFIG_USB_CONFIGFS_F_PTP=y CONFIG_USB_CONFIGFS_F_ACC=y CONFIG_USB_CONFIGFS_F_AUDIO_SRC=y CONFIG_USB_CONFIGFS_UEVENT=y # CONFIG_USB_CONFIGFS_F_UAC1 is not set # CONFIG_USB_CONFIGFS_F_UAC2 is not set CONFIG_USB_CONFIGFS_F_MIDI=y # CONFIG_USB_CONFIGFS_F_HID is not set # CONFIG_USB_CONFIGFS_F_UVC is not set # CONFIG_USB_CONFIGFS_F_PRINTER is not set # CONFIG_USB_ZERO is not set # CONFIG_USB_AUDIO is not set # CONFIG_USB_ETH is not set # CONFIG_USB_G_NCM is not set # CONFIG_USB_GADGETFS is not set # CONFIG_USB_FUNCTIONFS is not set # CONFIG_USB_MASS_STORAGE is not set # CONFIG_USB_G_SERIAL is not set # CONFIG_USB_MIDI_GADGET is not set # CONFIG_USB_G_PRINTER is not set # CONFIG_USB_CDC_COMPOSITE is not set # CONFIG_USB_G_ACM_MS is not set # CONFIG_USB_G_MULTI is not set # CONFIG_USB_G_HID is not set # CONFIG_USB_G_DBGP is not set # CONFIG_USB_G_WEBCAM is not set # CONFIG_USB_LED_TRIG is not set # CONFIG_UWB is not set CONFIG_MMC=y # CONFIG_MMC_DEBUG is not set # CONFIG_MMC_EMBEDDED_SDIO is not set CONFIG_MMC_PARANOID_SD_INIT=y # # MMC/SD/SDIO Card Drivers # CONFIG_MMC_BLOCK=y CONFIG_MMC_BLOCK_MINORS=64 CONFIG_MMC_BLOCK_BOUNCE=y # CONFIG_SDIO_UART is not set # CONFIG_MMC_TEST is not set # CONFIG_MMC_SIMULATE_MAX_SPEED is not set # # MMC/SD/SDIO Host Controller Drivers # CONFIG_MMC_ARMMMCI=y CONFIG_MMC_SDHCI=y # CONFIG_MMC_SDHCI_PCI is not set # CONFIG_MMC_SDHCI_ACPI is not set CONFIG_MMC_SDHCI_PLTFM=y # CONFIG_MMC_SDHCI_OF_ARASAN is not set # CONFIG_MMC_SDHCI_OF_AT91 is not set # CONFIG_MMC_SDHCI_F_SDH30 is not set # CONFIG_MMC_TIFM_SD is not set CONFIG_MMC_SPI=y # CONFIG_MMC_CB710 is not set # CONFIG_MMC_VIA_SDMMC is not set CONFIG_MMC_DW=y CONFIG_MMC_DW_PLTFM=y CONFIG_MMC_DW_EXYNOS=y CONFIG_MMC_DW_K3=y # CONFIG_MMC_DW_PCI is not set # CONFIG_MMC_VUB300 is not set # CONFIG_MMC_USHC is not set # CONFIG_MMC_USDHI6ROL0 is not set # CONFIG_MMC_TOSHIBA_PCI is not set # CONFIG_MMC_MTK is not set # CONFIG_MEMSTICK is not set CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y # CONFIG_LEDS_CLASS_FLASH is not set # # LED drivers # # CONFIG_LEDS_BCM6328 is not set # CONFIG_LEDS_BCM6358 is not set # CONFIG_LEDS_LM3530 is not set # CONFIG_LEDS_LM3642 is not set # CONFIG_LEDS_PCA9532 is not set CONFIG_LEDS_GPIO=y # CONFIG_LEDS_LP3944 is not set # CONFIG_LEDS_LP5521 is not set # CONFIG_LEDS_LP5523 is not set # CONFIG_LEDS_LP5562 is not set # CONFIG_LEDS_LP8501 is not set # CONFIG_LEDS_LP8860 is not set # CONFIG_LEDS_PCA955X is not set # CONFIG_LEDS_PCA963X is not set # CONFIG_LEDS_DAC124S085 is not set CONFIG_LEDS_REGULATOR=y # CONFIG_LEDS_BD2802 is not set # CONFIG_LEDS_INTEL_SS4200 is not set # CONFIG_LEDS_LT3593 is not set # CONFIG_LEDS_TCA6507 is not set # CONFIG_LEDS_TLC591XX is not set # CONFIG_LEDS_LM355x is not set # # LED driver for blink(1) USB RGB LED is under Special HID drivers (HID_THINGM) # # CONFIG_LEDS_BLINKM is not set CONFIG_LEDS_SYSCON=y # # LED Triggers # CONFIG_LEDS_TRIGGERS=y # CONFIG_LEDS_TRIGGER_TIMER is not set # CONFIG_LEDS_TRIGGER_ONESHOT is not set CONFIG_LEDS_TRIGGER_HEARTBEAT=y # CONFIG_LEDS_TRIGGER_BACKLIGHT is not set CONFIG_LEDS_TRIGGER_CPU=y # CONFIG_LEDS_TRIGGER_GPIO is not set # CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set # # iptables trigger is under Netfilter config (LED target) # # CONFIG_LEDS_TRIGGER_TRANSIENT is not set # CONFIG_LEDS_TRIGGER_CAMERA is not set # CONFIG_ACCESSIBILITY is not set # CONFIG_INFINIBAND is not set CONFIG_EDAC_SUPPORT=y # CONFIG_EDAC is not set CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" CONFIG_RTC_SYSTOHC=y CONFIG_RTC_SYSTOHC_DEVICE="rtc0" # CONFIG_RTC_DEBUG is not set # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set # CONFIG_RTC_DRV_TEST is not set # # I2C RTC drivers # # CONFIG_RTC_DRV_ABB5ZES3 is not set # CONFIG_RTC_DRV_ABX80X is not set # CONFIG_RTC_DRV_DS1307 is not set # CONFIG_RTC_DRV_DS1374 is not set # CONFIG_RTC_DRV_DS1672 is not set # CONFIG_RTC_DRV_DS3232 is not set # CONFIG_RTC_DRV_HYM8563 is not set # CONFIG_RTC_DRV_MAX6900 is not set # CONFIG_RTC_DRV_RS5C372 is not set # CONFIG_RTC_DRV_ISL1208 is not set # CONFIG_RTC_DRV_ISL12022 is not set # CONFIG_RTC_DRV_ISL12057 is not set # CONFIG_RTC_DRV_X1205 is not set # CONFIG_RTC_DRV_PCF2127 is not set # CONFIG_RTC_DRV_PCF8523 is not set # CONFIG_RTC_DRV_PCF8563 is not set # CONFIG_RTC_DRV_PCF85063 is not set # CONFIG_RTC_DRV_PCF8583 is not set # CONFIG_RTC_DRV_M41T80 is not set # CONFIG_RTC_DRV_BQ32K is not set # CONFIG_RTC_DRV_S35390A is not set # CONFIG_RTC_DRV_FM3130 is not set # CONFIG_RTC_DRV_RX8581 is not set # CONFIG_RTC_DRV_RX8025 is not set # CONFIG_RTC_DRV_EM3027 is not set # CONFIG_RTC_DRV_RV3029C2 is not set # CONFIG_RTC_DRV_RV8803 is not set # # SPI RTC drivers # # CONFIG_RTC_DRV_M41T93 is not set # CONFIG_RTC_DRV_M41T94 is not set # CONFIG_RTC_DRV_DS1305 is not set # CONFIG_RTC_DRV_DS1343 is not set # CONFIG_RTC_DRV_DS1347 is not set # CONFIG_RTC_DRV_DS1390 is not set # CONFIG_RTC_DRV_MAX6902 is not set # CONFIG_RTC_DRV_R9701 is not set # CONFIG_RTC_DRV_RS5C348 is not set # CONFIG_RTC_DRV_DS3234 is not set # CONFIG_RTC_DRV_PCF2123 is not set # CONFIG_RTC_DRV_RX4581 is not set # CONFIG_RTC_DRV_MCP795 is not set # # Platform RTC drivers # # CONFIG_RTC_DRV_DS1286 is not set # CONFIG_RTC_DRV_DS1511 is not set # CONFIG_RTC_DRV_DS1553 is not set # CONFIG_RTC_DRV_DS1685_FAMILY is not set # CONFIG_RTC_DRV_DS1742 is not set # CONFIG_RTC_DRV_DS2404 is not set CONFIG_RTC_DRV_EFI=y # CONFIG_RTC_DRV_STK17TA8 is not set # CONFIG_RTC_DRV_M48T86 is not set # CONFIG_RTC_DRV_M48T35 is not set # CONFIG_RTC_DRV_M48T59 is not set # CONFIG_RTC_DRV_MSM6242 is not set # CONFIG_RTC_DRV_BQ4802 is not set # CONFIG_RTC_DRV_RP5C01 is not set # CONFIG_RTC_DRV_V3020 is not set # CONFIG_RTC_DRV_ZYNQMP is not set # # on-CPU RTC drivers # # CONFIG_RTC_DRV_PL030 is not set CONFIG_RTC_DRV_PL031=y # CONFIG_RTC_DRV_SNVS is not set CONFIG_RTC_DRV_XGENE=y # # HID Sensor RTC drivers # # CONFIG_RTC_DRV_HID_SENSOR_TIME is not set CONFIG_DMADEVICES=y # CONFIG_DMADEVICES_DEBUG is not set # # DMA Devices # CONFIG_DMA_ENGINE=y CONFIG_DMA_VIRTUAL_CHANNELS=y CONFIG_DMA_ACPI=y CONFIG_DMA_OF=y # CONFIG_AMBA_PL08X is not set # CONFIG_FSL_EDMA is not set # CONFIG_INTEL_IDMA64 is not set CONFIG_K3_DMA=y # CONFIG_PL330_DMA is not set # CONFIG_XGENE_DMA is not set # CONFIG_DW_DMAC is not set # CONFIG_DW_DMAC_PCI is not set # # DMA Clients # # CONFIG_ASYNC_TX_DMA is not set # CONFIG_DMATEST is not set # CONFIG_AUXDISPLAY is not set # CONFIG_UIO is not set # CONFIG_VIRT_DRIVERS is not set CONFIG_VIRTIO=y # # Virtio drivers # # CONFIG_VIRTIO_PCI is not set CONFIG_VIRTIO_BALLOON=y # CONFIG_VIRTIO_INPUT is not set CONFIG_VIRTIO_MMIO=y # CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES is not set # # Microsoft Hyper-V guest support # CONFIG_STAGING=y # CONFIG_PRISM2_USB is not set # CONFIG_R8712U is not set # CONFIG_R8188EU is not set # CONFIG_R8723AU is not set # CONFIG_RTS5208 is not set # CONFIG_FB_SM750 is not set # CONFIG_FB_XGI is not set # # Speakup console speech # # CONFIG_SPEAKUP is not set # CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4 is not set # CONFIG_STAGING_MEDIA is not set # # Android # CONFIG_ASHMEM=y CONFIG_ANDROID_TIMED_OUTPUT=y CONFIG_ANDROID_TIMED_GPIO=y CONFIG_ANDROID_LOW_MEMORY_KILLER=y CONFIG_ANDROID_LOW_MEMORY_KILLER_AUTODETECT_OOM_ADJ_VALUES=y CONFIG_SYNC=y # CONFIG_SW_SYNC is not set CONFIG_ION=y # CONFIG_ION_TEST is not set # CONFIG_ION_DUMMY is not set CONFIG_ION_HISI=y CONFIG_FIQ_DEBUGGER=y CONFIG_FIQ_DEBUGGER_NO_SLEEP=y # CONFIG_FIQ_DEBUGGER_WAKEUP_IRQ_ALWAYS_ON is not set CONFIG_FIQ_DEBUGGER_CONSOLE=y CONFIG_FIQ_DEBUGGER_CONSOLE_DEFAULT_ENABLE=y CONFIG_FIQ_DEBUGGER_UART_OVERLAY=y # CONFIG_FIQ_WATCHDOG is not set # CONFIG_STAGING_BOARD is not set # CONFIG_WIMAX_GDM72XX is not set # CONFIG_DGNC is not set # CONFIG_DGAP is not set # CONFIG_GS_FPGABOOT is not set # CONFIG_COMMON_CLK_XLNX_CLKWZRD is not set # CONFIG_FB_TFT is not set # CONFIG_FSL_MC_BUS is not set # CONFIG_WILC1000_DRIVER is not set # CONFIG_MOST is not set # CONFIG_GOLDFISH is not set # CONFIG_CHROME_PLATFORMS is not set CONFIG_HISI_FIQ_DEBUGGER=y CONFIG_CLKDEV_LOOKUP=y CONFIG_HAVE_CLK_PREPARE=y CONFIG_COMMON_CLK=y # # Common Clock Framework # CONFIG_COMMON_CLK_VERSATILE=y CONFIG_CLK_SP810=y CONFIG_CLK_VEXPRESS_OSC=y # CONFIG_COMMON_CLK_SI5351 is not set # CONFIG_COMMON_CLK_SI514 is not set # CONFIG_COMMON_CLK_SI570 is not set # CONFIG_COMMON_CLK_CDCE925 is not set # CONFIG_CLK_QORIQ is not set CONFIG_COMMON_CLK_XGENE=y # CONFIG_COMMON_CLK_PXA is not set # CONFIG_COMMON_CLK_CDCE706 is not set CONFIG_COMMON_CLK_HI6220=y CONFIG_STUB_CLK_HI6220=y # # Hardware Spinlock drivers # # # Clock Source drivers # CONFIG_CLKSRC_OF=y CONFIG_CLKSRC_ACPI=y CONFIG_CLKSRC_PROBE=y CONFIG_CLKSRC_MMIO=y CONFIG_ARM_ARCH_TIMER=y CONFIG_ARM_ARCH_TIMER_EVTSTREAM=y CONFIG_ARM_TIMER_SP804=y # CONFIG_ATMEL_PIT is not set # CONFIG_SH_TIMER_CMT is not set # CONFIG_SH_TIMER_MTU2 is not set # CONFIG_SH_TIMER_TMU is not set # CONFIG_EM_TIMER_STI is not set CONFIG_MAILBOX=y # CONFIG_ARM_MHU is not set # CONFIG_PL320_MBOX is not set # CONFIG_PCC is not set # CONFIG_ALTERA_MBOX is not set CONFIG_HI6220_MBOX=y # CONFIG_MAILBOX_TEST is not set # CONFIG_IOMMU_SUPPORT is not set # # Remoteproc drivers # # CONFIG_STE_MODEM_RPROC is not set # # Rpmsg drivers # # # SOC (System On Chip) specific Drivers # # CONFIG_SUNXI_SRAM is not set # CONFIG_SOC_TI is not set # CONFIG_PM_DEVFREQ is not set # CONFIG_EXTCON is not set # CONFIG_MEMORY is not set # CONFIG_IIO is not set # CONFIG_NTB is not set # CONFIG_VME_BUS is not set # CONFIG_PWM is not set CONFIG_IRQCHIP=y CONFIG_ARM_GIC=y CONFIG_ARM_GIC_V2M=y CONFIG_ARM_GIC_V3=y CONFIG_ARM_GIC_V3_ITS=y # CONFIG_IPACK_BUS is not set CONFIG_RESET_CONTROLLER=y CONFIG_COMMON_RESET_HI6220=y # CONFIG_FMC is not set # # PHY Subsystem # CONFIG_GENERIC_PHY=y # CONFIG_PHY_PXA_28NM_HSIC is not set # CONFIG_PHY_PXA_28NM_USB2 is not set # CONFIG_BCM_KONA_USB2_PHY is not set CONFIG_PHY_HI6220_USB=y # CONFIG_PHY_SAMSUNG_USB2 is not set CONFIG_PHY_XGENE=y # CONFIG_POWERCAP is not set # CONFIG_MCB is not set # # Performance monitor support # CONFIG_ARM_PMU=y CONFIG_RAS=y # CONFIG_THUNDERBOLT is not set # # Android # CONFIG_ANDROID=y CONFIG_ANDROID_BINDER_IPC=y # CONFIG_LIBNVDIMM is not set # CONFIG_NVMEM is not set # CONFIG_STM is not set # CONFIG_STM_DUMMY is not set # CONFIG_STM_SOURCE_CONSOLE is not set # CONFIG_INTEL_TH is not set # # FPGA Configuration Support # # CONFIG_FPGA is not set # # Firmware Drivers # CONFIG_ARM_PSCI_FW=y # CONFIG_FIRMWARE_MEMMAP is not set CONFIG_DMIID=y # CONFIG_DMI_SYSFS is not set CONFIG_REBOOT_REASON_SRAM=y # # EFI (Extensible Firmware Interface) Support # CONFIG_EFI_VARS=y CONFIG_EFI_ESRT=y CONFIG_EFI_VARS_PSTORE=y CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE=y CONFIG_EFI_PARAMS_FROM_FDT=y CONFIG_EFI_RUNTIME_WRAPPERS=y CONFIG_EFI_ARMSTUB=y CONFIG_ACPI=y CONFIG_ACPI_GENERIC_GSI=y CONFIG_ACPI_CCA_REQUIRED=y # CONFIG_ACPI_DEBUGGER is not set # CONFIG_ACPI_EC_DEBUGFS is not set CONFIG_ACPI_BUTTON=y CONFIG_ACPI_FAN=y # CONFIG_ACPI_DOCK is not set CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_CUSTOM_DSDT is not set # CONFIG_ACPI_DEBUG is not set # CONFIG_ACPI_PCI_SLOT is not set CONFIG_ACPI_CONTAINER=y # CONFIG_ACPI_HED is not set # CONFIG_ACPI_CUSTOM_METHOD is not set CONFIG_ACPI_REDUCED_HARDWARE_ONLY=y # CONFIG_PMIC_OPREGION is not set # # File systems # CONFIG_DCACHE_WORD_ACCESS=y # CONFIG_EXT2_FS is not set # CONFIG_EXT3_FS is not set CONFIG_EXT4_FS=y CONFIG_EXT4_USE_FOR_EXT2=y # CONFIG_EXT4_FS_POSIX_ACL is not set CONFIG_EXT4_FS_SECURITY=y CONFIG_EXT4_ENCRYPTION=y CONFIG_EXT4_FS_ENCRYPTION=y # CONFIG_EXT4_DEBUG is not set CONFIG_JBD2=y # CONFIG_JBD2_DEBUG is not set CONFIG_FS_MBCACHE=y # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set # CONFIG_XFS_FS is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set CONFIG_BTRFS_FS=y # CONFIG_BTRFS_FS_POSIX_ACL is not set # CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set # CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set # CONFIG_BTRFS_DEBUG is not set # CONFIG_BTRFS_ASSERT is not set # CONFIG_NILFS2_FS is not set # CONFIG_F2FS_FS is not set # CONFIG_FS_DAX is not set CONFIG_FS_POSIX_ACL=y CONFIG_EXPORTFS=y CONFIG_FILE_LOCKING=y CONFIG_FSNOTIFY=y CONFIG_DNOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_FANOTIFY=y CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y CONFIG_QUOTA=y # CONFIG_QUOTA_NETLINK_INTERFACE is not set CONFIG_PRINT_QUOTA_WARNING=y # CONFIG_QUOTA_DEBUG is not set CONFIG_QUOTA_TREE=y # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y CONFIG_AUTOFS4_FS=y CONFIG_FUSE_FS=y CONFIG_CUSE=y CONFIG_OVERLAY_FS=y # # Caches # # CONFIG_FSCACHE is not set # # CD-ROM/DVD Filesystems # # CONFIG_ISO9660_FS is not set # CONFIG_UDF_FS is not set # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y # CONFIG_PROC_KCORE is not set CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y # CONFIG_PROC_CHILDREN is not set CONFIG_KERNFS=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_TMPFS_XATTR=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_CONFIGFS_FS=y CONFIG_EFIVAR_FS=y CONFIG_MISC_FILESYSTEMS=y # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_ECRYPT_FS is not set # CONFIG_SDCARD_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_LOGFS is not set # CONFIG_CRAMFS is not set CONFIG_SQUASHFS=y # CONFIG_SQUASHFS_FILE_CACHE is not set CONFIG_SQUASHFS_FILE_DIRECT=y # CONFIG_SQUASHFS_DECOMP_SINGLE is not set # CONFIG_SQUASHFS_DECOMP_MULTI is not set CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU=y CONFIG_SQUASHFS_XATTR=y CONFIG_SQUASHFS_ZLIB=y CONFIG_SQUASHFS_LZ4=y # CONFIG_SQUASHFS_LZO is not set CONFIG_SQUASHFS_XZ=y # CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set # CONFIG_SQUASHFS_EMBEDDED is not set CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3 # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_OMFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_QNX6FS_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_PSTORE=y CONFIG_PSTORE_CONSOLE=y CONFIG_PSTORE_PMSG=y CONFIG_PSTORE_FTRACE=y CONFIG_PSTORE_RAM=y # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=y # CONFIG_NFS_V2 is not set CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y # CONFIG_NFS_SWAP is not set # CONFIG_NFS_V4_1 is not set CONFIG_ROOT_NFS=y # CONFIG_NFS_USE_LEGACY_DNS is not set CONFIG_NFS_USE_KERNEL_DNS=y # CONFIG_NFSD is not set CONFIG_GRACE_PERIOD=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_NFS_ACL_SUPPORT=y CONFIG_NFS_COMMON=y CONFIG_SUNRPC=y CONFIG_SUNRPC_GSS=y CONFIG_RPCSEC_GSS_KRB5=y # CONFIG_SUNRPC_DEBUG is not set # CONFIG_CEPH_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set CONFIG_9P_FS=y # CONFIG_9P_FS_POSIX_ACL is not set # CONFIG_9P_FS_SECURITY is not set CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ASCII is not set CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_MAC_ROMAN is not set # CONFIG_NLS_MAC_CELTIC is not set # CONFIG_NLS_MAC_CENTEURO is not set # CONFIG_NLS_MAC_CROATIAN is not set # CONFIG_NLS_MAC_CYRILLIC is not set # CONFIG_NLS_MAC_GAELIC is not set # CONFIG_NLS_MAC_GREEK is not set # CONFIG_NLS_MAC_ICELAND is not set # CONFIG_NLS_MAC_INUIT is not set # CONFIG_NLS_MAC_ROMANIAN is not set # CONFIG_NLS_MAC_TURKISH is not set # CONFIG_NLS_UTF8 is not set # CONFIG_DLM is not set CONFIG_HAVE_KVM_IRQFD=y CONFIG_HAVE_KVM_EVENTFD=y CONFIG_KVM_MMIO=y CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y CONFIG_KVM_VFIO=y CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL=y CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT=y CONFIG_KVM_COMPAT=y CONFIG_VIRTUALIZATION=y CONFIG_KVM_ARM_VGIC_V3=y CONFIG_KVM=y CONFIG_KVM_ARM_HOST=y # # Kernel hacking # # # printk and dmesg options # CONFIG_PRINTK_TIME=y CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4 # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_DYNAMIC_DEBUG is not set # # Compile-time checks and compiler options # CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_INFO_REDUCED is not set # CONFIG_DEBUG_INFO_SPLIT is not set # CONFIG_DEBUG_INFO_DWARF4 is not set # CONFIG_GDB_SCRIPTS is not set CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=2048 # CONFIG_STRIP_ASM_SYMS is not set # CONFIG_READABLE_ASM is not set # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_PAGE_OWNER is not set CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set # CONFIG_DEBUG_SECTION_MISMATCH is not set CONFIG_SECTION_MISMATCH_WARN_ONLY=y CONFIG_ARCH_WANT_FRAME_POINTERS=y CONFIG_FRAME_POINTER=y # CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set CONFIG_MAGIC_SYSRQ=y CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1 CONFIG_DEBUG_KERNEL=y # # Memory Debugging # # CONFIG_PAGE_EXTENSION is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUG_OBJECTS is not set # CONFIG_DEBUG_SLAB is not set CONFIG_HAVE_DEBUG_KMEMLEAK=y # CONFIG_DEBUG_KMEMLEAK is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_MEMORY_INIT is not set # CONFIG_DEBUG_PER_CPU_MAPS is not set CONFIG_HAVE_ARCH_KASAN=y # CONFIG_DEBUG_SHIRQ is not set # # Debug Lockups and Hangs # CONFIG_LOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR_OTHER_CPU=y CONFIG_HARDLOCKUP_DETECTOR=y # CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0 # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 CONFIG_DETECT_HUNG_TASK=y CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120 # CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0 CONFIG_PANIC_ON_OOPS=y CONFIG_PANIC_ON_OOPS_VALUE=1 CONFIG_PANIC_TIMEOUT=5 # CONFIG_SCHED_DEBUG is not set CONFIG_SCHED_INFO=y CONFIG_SCHEDSTATS=y # CONFIG_SCHED_STACK_END_CHECK is not set # CONFIG_DEBUG_TIMEKEEPING is not set CONFIG_TIMER_STATS=y CONFIG_DEBUG_PREEMPT=y # # Lock Debugging (spinlocks, mutexes, etc...) # # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_ATOMIC_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_LOCK_TORTURE_TEST is not set CONFIG_TRACE_IRQFLAGS=y CONFIG_STACKTRACE=y # CONFIG_DEBUG_KOBJECT is not set CONFIG_HAVE_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_LIST is not set # CONFIG_DEBUG_PI_LIST is not set # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_NOTIFIERS is not set # CONFIG_DEBUG_CREDENTIALS is not set # # RCU Debugging # # CONFIG_PROVE_RCU is not set # CONFIG_SPARSE_RCU_POINTER is not set # CONFIG_TORTURE_TEST is not set # CONFIG_RCU_TORTURE_TEST is not set CONFIG_RCU_CPU_STALL_TIMEOUT=21 # CONFIG_RCU_TRACE is not set # CONFIG_RCU_EQS_DEBUG is not set # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set # CONFIG_NOTIFIER_ERROR_INJECTION is not set # CONFIG_FAULT_INJECTION is not set CONFIG_NOP_TRACER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HAVE_C_RECORDMCOUNT=y CONFIG_TRACER_MAX_TRACE=y CONFIG_TRACE_CLOCK=y CONFIG_RING_BUFFER=y CONFIG_EVENT_TRACING=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_RING_BUFFER_ALLOW_SWAP=y CONFIG_TRACING=y CONFIG_GENERIC_TRACER=y CONFIG_TRACING_SUPPORT=y CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y CONFIG_IRQSOFF_TRACER=y CONFIG_PREEMPT_TRACER=y CONFIG_SCHED_TRACER=y CONFIG_FTRACE_SYSCALLS=y CONFIG_TRACER_SNAPSHOT=y CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP=y CONFIG_BRANCH_PROFILE_NONE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set # CONFIG_PROFILE_ALL_BRANCHES is not set # CONFIG_STACK_TRACER is not set CONFIG_BLK_DEV_IO_TRACE=y # CONFIG_PROBE_EVENTS is not set CONFIG_DYNAMIC_FTRACE=y CONFIG_FUNCTION_PROFILER=y CONFIG_FTRACE_MCOUNT_RECORD=y # CONFIG_FTRACE_STARTUP_TEST is not set # CONFIG_TRACEPOINT_BENCHMARK is not set # CONFIG_RING_BUFFER_BENCHMARK is not set # CONFIG_RING_BUFFER_STARTUP_TEST is not set # CONFIG_TRACE_ENUM_MAP_FILE is not set CONFIG_TRACING_EVENTS_GPIO=y # # Runtime Testing # # CONFIG_LKDTM is not set # CONFIG_TEST_LIST_SORT is not set # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_RBTREE_TEST is not set # CONFIG_ATOMIC64_SELFTEST is not set # CONFIG_TEST_HEXDUMP is not set # CONFIG_TEST_STRING_HELPERS is not set # CONFIG_TEST_KSTRTOX is not set # CONFIG_TEST_PRINTF is not set # CONFIG_TEST_RHASHTABLE is not set # CONFIG_DMA_API_DEBUG is not set # CONFIG_TEST_FIRMWARE is not set # CONFIG_TEST_UDELAY is not set # CONFIG_MEMTEST is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set # CONFIG_ARM64_PTDUMP is not set # CONFIG_STRICT_DEVMEM is not set # CONFIG_PID_IN_CONTEXTIDR is not set # CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET is not set CONFIG_DEBUG_RODATA=y # CONFIG_DEBUG_ALIGN_RODATA is not set # CONFIG_CORESIGHT is not set # # Security options # CONFIG_KEYS=y # CONFIG_PERSISTENT_KEYRINGS is not set # CONFIG_BIG_KEYS is not set CONFIG_ENCRYPTED_KEYS=y # CONFIG_SECURITY_DMESG_RESTRICT is not set # CONFIG_SECURITY_PERF_EVENTS_RESTRICT is not set CONFIG_SECURITY=y # CONFIG_SECURITYFS is not set CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_NETWORK_XFRM=y # CONFIG_SECURITY_PATH is not set CONFIG_LSM_MMAP_MIN_ADDR=4096 CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=0 # CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set # CONFIG_SECURITY_SMACK is not set # CONFIG_SECURITY_TOMOYO is not set # CONFIG_SECURITY_APPARMOR is not set # CONFIG_SECURITY_YAMA is not set CONFIG_INTEGRITY=y # CONFIG_INTEGRITY_SIGNATURE is not set CONFIG_INTEGRITY_AUDIT=y # CONFIG_IMA is not set # CONFIG_EVM is not set CONFIG_DEFAULT_SECURITY_SELINUX=y # CONFIG_DEFAULT_SECURITY_DAC is not set CONFIG_DEFAULT_SECURITY="selinux" CONFIG_XOR_BLOCKS=y CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=y CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_RNG_DEFAULT=y CONFIG_CRYPTO_PCOMP2=y CONFIG_CRYPTO_AKCIPHER2=y # CONFIG_CRYPTO_RSA is not set CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y # CONFIG_CRYPTO_USER is not set CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y CONFIG_CRYPTO_GF128MUL=y CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_NULL2=y # CONFIG_CRYPTO_PCRYPT is not set CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=y # CONFIG_CRYPTO_MCRYPTD is not set CONFIG_CRYPTO_AUTHENC=y CONFIG_CRYPTO_ABLK_HELPER=y # # Authenticated Encryption with Associated Data # CONFIG_CRYPTO_CCM=y CONFIG_CRYPTO_GCM=y # CONFIG_CRYPTO_CHACHA20POLY1305 is not set CONFIG_CRYPTO_SEQIV=y CONFIG_CRYPTO_ECHAINIV=y # # Block modes # CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_CTR=y CONFIG_CRYPTO_CTS=y CONFIG_CRYPTO_ECB=y # CONFIG_CRYPTO_LRW is not set # CONFIG_CRYPTO_PCBC is not set CONFIG_CRYPTO_XTS=y # CONFIG_CRYPTO_KEYWRAP is not set # # Hash modes # CONFIG_CRYPTO_CMAC=y CONFIG_CRYPTO_HMAC=y # CONFIG_CRYPTO_XCBC is not set # CONFIG_CRYPTO_VMAC is not set # # Digest # CONFIG_CRYPTO_CRC32C=y # CONFIG_CRYPTO_CRC32 is not set CONFIG_CRYPTO_CRCT10DIF=y CONFIG_CRYPTO_GHASH=y # CONFIG_CRYPTO_POLY1305 is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=y # CONFIG_CRYPTO_RMD128 is not set # CONFIG_CRYPTO_RMD160 is not set # CONFIG_CRYPTO_RMD256 is not set # CONFIG_CRYPTO_RMD320 is not set CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA256=y # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_WP512 is not set # # Ciphers # CONFIG_CRYPTO_AES=y # CONFIG_CRYPTO_ANUBIS is not set CONFIG_CRYPTO_ARC4=y # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set CONFIG_CRYPTO_DES=y # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_SALSA20 is not set # CONFIG_CRYPTO_CHACHA20 is not set # CONFIG_CRYPTO_SEED is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_TEA is not set CONFIG_CRYPTO_TWOFISH=y CONFIG_CRYPTO_TWOFISH_COMMON=y # # Compression # CONFIG_CRYPTO_DEFLATE=y # CONFIG_CRYPTO_ZLIB is not set # CONFIG_CRYPTO_LZO is not set # CONFIG_CRYPTO_842 is not set # CONFIG_CRYPTO_LZ4 is not set # CONFIG_CRYPTO_LZ4HC is not set # # Random Number Generation # # CONFIG_CRYPTO_ANSI_CPRNG is not set CONFIG_CRYPTO_DRBG_MENU=y CONFIG_CRYPTO_DRBG_HMAC=y # CONFIG_CRYPTO_DRBG_HASH is not set # CONFIG_CRYPTO_DRBG_CTR is not set CONFIG_CRYPTO_DRBG=y CONFIG_CRYPTO_JITTERENTROPY=y # CONFIG_CRYPTO_USER_API_HASH is not set # CONFIG_CRYPTO_USER_API_SKCIPHER is not set # CONFIG_CRYPTO_USER_API_RNG is not set # CONFIG_CRYPTO_USER_API_AEAD is not set CONFIG_CRYPTO_HW=y # CONFIG_CRYPTO_DEV_CCP is not set # CONFIG_ASYMMETRIC_KEY_TYPE is not set # # Certificates for signature checking # # CONFIG_SYSTEM_TRUSTED_KEYRING is not set CONFIG_ARM64_CRYPTO=y CONFIG_CRYPTO_SHA1_ARM64_CE=y CONFIG_CRYPTO_SHA2_ARM64_CE=y CONFIG_CRYPTO_GHASH_ARM64_CE=y CONFIG_CRYPTO_AES_ARM64_CE=y CONFIG_CRYPTO_AES_ARM64_CE_CCM=y CONFIG_CRYPTO_AES_ARM64_CE_BLK=y CONFIG_CRYPTO_AES_ARM64_NEON_BLK=y # CONFIG_CRYPTO_CRC32_ARM64 is not set CONFIG_BINARY_PRINTF=y # # Library routines # CONFIG_RAID6_PQ=y CONFIG_BITREVERSE=y CONFIG_HAVE_ARCH_BITREVERSE=y CONFIG_RATIONAL=y CONFIG_GENERIC_STRNCPY_FROM_USER=y CONFIG_GENERIC_STRNLEN_USER=y CONFIG_GENERIC_NET_UTILS=y CONFIG_GENERIC_PCI_IOMAP=y CONFIG_GENERIC_IO=y CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y CONFIG_CRC_CCITT=y CONFIG_CRC16=y CONFIG_CRC_T10DIF=y CONFIG_CRC_ITU_T=y CONFIG_CRC32=y # CONFIG_CRC32_SELFTEST is not set CONFIG_CRC32_SLICEBY8=y # CONFIG_CRC32_SLICEBY4 is not set # CONFIG_CRC32_SARWATE is not set # CONFIG_CRC32_BIT is not set CONFIG_CRC7=y CONFIG_LIBCRC32C=y # CONFIG_CRC8 is not set CONFIG_AUDIT_GENERIC=y CONFIG_AUDIT_ARCH_COMPAT_GENERIC=y CONFIG_AUDIT_COMPAT_GENERIC=y # CONFIG_RANDOM32_SELFTEST is not set CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y CONFIG_LZ4_DECOMPRESS=y CONFIG_XZ_DEC=y CONFIG_XZ_DEC_X86=y CONFIG_XZ_DEC_POWERPC=y CONFIG_XZ_DEC_IA64=y CONFIG_XZ_DEC_ARM=y CONFIG_XZ_DEC_ARMTHUMB=y CONFIG_XZ_DEC_SPARC=y CONFIG_XZ_DEC_BCJ=y # CONFIG_XZ_DEC_TEST is not set CONFIG_DECOMPRESS_GZIP=y CONFIG_DECOMPRESS_BZIP2=y CONFIG_DECOMPRESS_LZMA=y CONFIG_DECOMPRESS_XZ=y CONFIG_DECOMPRESS_LZO=y CONFIG_DECOMPRESS_LZ4=y CONFIG_GENERIC_ALLOCATOR=y CONFIG_REED_SOLOMON=y CONFIG_REED_SOLOMON_ENC8=y CONFIG_REED_SOLOMON_DEC8=y CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=y CONFIG_TEXTSEARCH_BM=y CONFIG_TEXTSEARCH_FSM=y CONFIG_ASSOCIATIVE_ARRAY=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT_MAP=y CONFIG_HAS_DMA=y CONFIG_CPU_RMAP=y CONFIG_DQL=y CONFIG_GLOB=y # CONFIG_GLOB_SELFTEST is not set CONFIG_NLATTR=y CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y # CONFIG_CORDIC is not set # CONFIG_DDR is not set CONFIG_LIBFDT=y CONFIG_OID_REGISTRY=y CONFIG_UCS2_STRING=y # CONFIG_SG_SPLIT is not set CONFIG_ARCH_HAS_SG_CHAIN=y ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 18:13 ` Dmitry Shmidt @ 2016-07-13 18:32 ` Paul E. McKenney 0 siblings, 0 replies; 67+ messages in thread From: Paul E. McKenney @ 2016-07-13 18:32 UTC (permalink / raw) To: Dmitry Shmidt Cc: Peter Zijlstra, John Stultz, Tejun Heo, Ingo Molnar, lkml, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 11:13:26AM -0700, Dmitry Shmidt wrote: > On Wed, Jul 13, 2016 at 7:42 AM, Paul E. McKenney > <paulmck@linux.vnet.ibm.com> wrote: > > On Wed, Jul 13, 2016 at 10:21:12AM +0200, Peter Zijlstra wrote: > >> On Tue, Jul 12, 2016 at 05:00:04PM -0700, John Stultz wrote: > >> > Hey Tejun, > >> > > >> > So Dmitry Shmidt recently noticed that with 4.4 based systems we're > >> > seeing quite a bit of performance overhead from > >> > __cgroup_procs_write(). > >> > > >> > With 4.4 tree as it stands, we're seeing __cgroup_procs_write() quite > >> > often take 10s of miliseconds to execute (with max times up in the > >> > 80ms range). > >> > > >> > While with 4.1 it was quite often in the single usec range, and max > >> > time values still in in sub-milisecond range. > >> > > >> > The majority of these performance regressions seem to come from the > >> > locking changes in: > >> > > >> > 3014dde762f6 ("cgroup: simplify threadgroup locking") > >> > and > >> > 1ed1328792ff ("sched, cgroup: replace signal_struct->group_rwsem with > >> > a global percpu_rwsem") > >> > > >> > Dmitry has found that by reverting these two changes (which don't > >> > revert easiliy), we can get back down to tens 10-100 usec range for > >> > most calls, with max values occasionally spiking to ~18ms. > >> > > >> > Those two commits do talk about performance regressions, that were > >> > supposedly alleviated by percpu_rwsem changes, but I'm not sure we are > >> > seeing this. > >> > >> Do you have 'funny' RCU options that quickly force a grace period when > >> you go idle or something? > >> > >> But yes, it does not surprise me to find this commit is causing > >> problems. > > > > Hmmm... Looks like RCU is present both before and after. But please > > do send along your .config. > > Attached No funny RCU Kconfig options set -- vanilla preemptible RCU. > > Speaking of .config, is CONFIG_PREEMPT=y? If so, does the workload > > feature preemption and migration? If that is the case, you might be > > seeing contention on the per-CPU cgroup_threadgroup_rwsem, given that > > the second patch seems to be adding acquisitions. > > CONFIG_PREEMPT=y is set. > We see this issue during the boot, so it supposes to be enough CPU load to > cause preemption and migration. How early during boot? Presumably after the scheduler has started... Thanx, Paul ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 0:00 Severe performance regression w/ 4.4+ on Android due to cgroup locking changes John Stultz 2016-07-13 8:21 ` Peter Zijlstra @ 2016-07-13 18:21 ` Tejun Heo 2016-07-13 18:33 ` Tejun Heo 2016-07-13 20:44 ` Colin Cross 1 sibling, 2 replies; 67+ messages in thread From: Tejun Heo @ 2016-07-13 18:21 UTC (permalink / raw) To: John Stultz Cc: Ingo Molnar, Peter Zijlstra, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov (cc'ing Oleg) Hello, On Tue, Jul 12, 2016 at 05:00:04PM -0700, John Stultz wrote: > So Dmitry Shmidt recently noticed that with 4.4 based systems we're > seeing quite a bit of performance overhead from > __cgroup_procs_write(). > > With 4.4 tree as it stands, we're seeing __cgroup_procs_write() quite > often take 10s of miliseconds to execute (with max times up in the > 80ms range). Yikes, that's pretty high. Does this happen only while the system is generally busy or regardless of overall load? > While with 4.1 it was quite often in the single usec range, and max > time values still in in sub-milisecond range. > > The majority of these performance regressions seem to come from the > locking changes in: > > 3014dde762f6 ("cgroup: simplify threadgroup locking") > and > 1ed1328792ff ("sched, cgroup: replace signal_struct->group_rwsem with > a global percpu_rwsem") > > Dmitry has found that by reverting these two changes (which don't > revert easiliy), we can get back down to tens 10-100 usec range for > most calls, with max values occasionally spiking to ~18ms. > > Those two commits do talk about performance regressions, that were > supposedly alleviated by percpu_rwsem changes, but I'm not sure we are > seeing this. > > In 1ed1328792ff, the commit talks about the write path being a fairly > cold path, but with Android I worry this may not actually be the case, > as Android uses cpuset cgroups to group tasks into foreground and > background tasks, but this means when switching applications, tasks > are migrated between cgroups. Putting an additional 80 milisecond > delay on this adds potentially visible latencies on task switching. Switching between foreground and background isn't a hot path. It's human initiated operations after all. It taking 80 msecs sure is problematic but I'm skeptical that this is from actual contention given that the only reader side holders are fork and exit paths. > Reverting those two changes in the Android common.git tree doesn't > feel like a good long term solution here, so I was wondering if you > had any thoughts on how to further reduce the performance regression > here? One interesting thing to try would be replacing it with a regular non-percpu rwsem and see how it behaves. That should easily tell us whether this is from actual contention or artifacts from percpu_rwsem implementation. Thanks. -- tejun ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 18:21 ` Tejun Heo @ 2016-07-13 18:33 ` Tejun Heo 2016-07-13 20:13 ` John Stultz 2016-07-13 20:31 ` Dmitry Shmidt 2016-07-13 20:44 ` Colin Cross 1 sibling, 2 replies; 67+ messages in thread From: Tejun Heo @ 2016-07-13 18:33 UTC (permalink / raw) To: John Stultz Cc: Ingo Molnar, Peter Zijlstra, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 02:21:02PM -0400, Tejun Heo wrote: > One interesting thing to try would be replacing it with a regular > non-percpu rwsem and see how it behaves. That should easily tell us > whether this is from actual contention or artifacts from percpu_rwsem > implementation. So, something like the following. Can you please see whether this makes any difference? Thanks. diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h index 5b17de6..bc1e4d8 100644 --- a/include/linux/cgroup-defs.h +++ b/include/linux/cgroup-defs.h @@ -14,7 +14,7 @@ #include <linux/mutex.h> #include <linux/rcupdate.h> #include <linux/percpu-refcount.h> -#include <linux/percpu-rwsem.h> +#include <linux/rwsem.h> #include <linux/workqueue.h> #ifdef CONFIG_CGROUPS @@ -518,7 +518,7 @@ struct cgroup_subsys { unsigned int depends_on; }; -extern struct percpu_rw_semaphore cgroup_threadgroup_rwsem; +extern struct rw_semaphore cgroup_threadgroup_rwsem; /** * cgroup_threadgroup_change_begin - threadgroup exclusion for cgroups @@ -529,7 +529,7 @@ extern struct percpu_rw_semaphore cgroup_threadgroup_rwsem; */ static inline void cgroup_threadgroup_change_begin(struct task_struct *tsk) { - percpu_down_read(&cgroup_threadgroup_rwsem); + down_read(&cgroup_threadgroup_rwsem); } /** @@ -541,7 +541,7 @@ static inline void cgroup_threadgroup_change_begin(struct task_struct *tsk) */ static inline void cgroup_threadgroup_change_end(struct task_struct *tsk) { - percpu_up_read(&cgroup_threadgroup_rwsem); + up_read(&cgroup_threadgroup_rwsem); } #else /* CONFIG_CGROUPS */ diff --git a/kernel/cgroup.c b/kernel/cgroup.c index 86cb5c6..ed9c142 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -113,7 +113,7 @@ static DEFINE_SPINLOCK(cgroup_file_kn_lock); */ static DEFINE_SPINLOCK(release_agent_path_lock); -struct percpu_rw_semaphore cgroup_threadgroup_rwsem; +DECLARE_RWSEM(cgroup_threadgroup_rwsem); #define cgroup_assert_mutex_or_rcu_locked() \ RCU_LOCKDEP_WARN(!rcu_read_lock_held() && \ @@ -2899,7 +2899,7 @@ static ssize_t __cgroup_procs_write(struct kernfs_open_file *of, char *buf, if (!cgrp) return -ENODEV; - percpu_down_write(&cgroup_threadgroup_rwsem); + down_write(&cgroup_threadgroup_rwsem); rcu_read_lock(); if (pid) { tsk = find_task_by_vpid(pid); @@ -2937,7 +2937,7 @@ static ssize_t __cgroup_procs_write(struct kernfs_open_file *of, char *buf, out_unlock_rcu: rcu_read_unlock(); out_unlock_threadgroup: - percpu_up_write(&cgroup_threadgroup_rwsem); + up_write(&cgroup_threadgroup_rwsem); for_each_subsys(ss, ssid) if (ss->post_attach) ss->post_attach(); @@ -3077,7 +3077,7 @@ static int cgroup_update_dfl_csses(struct cgroup *cgrp) lockdep_assert_held(&cgroup_mutex); - percpu_down_write(&cgroup_threadgroup_rwsem); + down_write(&cgroup_threadgroup_rwsem); /* look up all csses currently attached to @cgrp's subtree */ spin_lock_bh(&css_set_lock); @@ -3112,7 +3112,7 @@ static int cgroup_update_dfl_csses(struct cgroup *cgrp) ret = cgroup_taskset_migrate(&tset, cgrp->root); out_finish: cgroup_migrate_finish(&preloaded_csets); - percpu_up_write(&cgroup_threadgroup_rwsem); + up_write(&cgroup_threadgroup_rwsem); return ret; } @@ -5601,7 +5601,7 @@ int __init cgroup_init(void) int ssid; BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16); - BUG_ON(percpu_init_rwsem(&cgroup_threadgroup_rwsem)); + //BUG_ON(percpu_init_rwsem(&cgroup_threadgroup_rwsem)); BUG_ON(cgroup_init_cftypes(NULL, cgroup_dfl_base_files)); BUG_ON(cgroup_init_cftypes(NULL, cgroup_legacy_base_files)); ^ permalink raw reply related [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 18:33 ` Tejun Heo @ 2016-07-13 20:13 ` John Stultz 2016-07-13 20:18 ` Tejun Heo 2016-07-13 20:31 ` Dmitry Shmidt 1 sibling, 1 reply; 67+ messages in thread From: John Stultz @ 2016-07-13 20:13 UTC (permalink / raw) To: Tejun Heo Cc: Ingo Molnar, Peter Zijlstra, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 11:33 AM, Tejun Heo <tj@kernel.org> wrote: > On Wed, Jul 13, 2016 at 02:21:02PM -0400, Tejun Heo wrote: >> One interesting thing to try would be replacing it with a regular >> non-percpu rwsem and see how it behaves. That should easily tell us >> whether this is from actual contention or artifacts from percpu_rwsem >> implementation. > > So, something like the following. Can you please see whether this > makes any difference? Yea. So this brings it down for me closer to what we're seeing with the Dmitry's patch reverting the two problematic commits, usually 10-50us with one early spike at 18ms. thanks -john ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 20:13 ` John Stultz @ 2016-07-13 20:18 ` Tejun Heo 2016-07-13 20:26 ` Peter Zijlstra 0 siblings, 1 reply; 67+ messages in thread From: Tejun Heo @ 2016-07-13 20:18 UTC (permalink / raw) To: John Stultz Cc: Ingo Molnar, Peter Zijlstra, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov, Paul E. McKenney Hello, John. On Wed, Jul 13, 2016 at 01:13:11PM -0700, John Stultz wrote: > On Wed, Jul 13, 2016 at 11:33 AM, Tejun Heo <tj@kernel.org> wrote: > > On Wed, Jul 13, 2016 at 02:21:02PM -0400, Tejun Heo wrote: > >> One interesting thing to try would be replacing it with a regular > >> non-percpu rwsem and see how it behaves. That should easily tell us > >> whether this is from actual contention or artifacts from percpu_rwsem > >> implementation. > > > > So, something like the following. Can you please see whether this > > makes any difference? > > Yea. So this brings it down for me closer to what we're seeing with > the Dmitry's patch reverting the two problematic commits, usually > 10-50us with one early spike at 18ms. So, it's a percpu rwsem issue then. I haven't really followed the perpcpu rwsem changes closely. Oleg, are multi-milisec delay expected on down write expected with the current implementation of percpu_rwsem? Thanks. -- tejun ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 20:18 ` Tejun Heo @ 2016-07-13 20:26 ` Peter Zijlstra 2016-07-13 20:39 ` Tejun Heo 2016-07-13 20:52 ` Paul E. McKenney 0 siblings, 2 replies; 67+ messages in thread From: Peter Zijlstra @ 2016-07-13 20:26 UTC (permalink / raw) To: Tejun Heo Cc: John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov, Paul E. McKenney On Wed, Jul 13, 2016 at 04:18:23PM -0400, Tejun Heo wrote: > Hello, John. > > On Wed, Jul 13, 2016 at 01:13:11PM -0700, John Stultz wrote: > > On Wed, Jul 13, 2016 at 11:33 AM, Tejun Heo <tj@kernel.org> wrote: > > > On Wed, Jul 13, 2016 at 02:21:02PM -0400, Tejun Heo wrote: > > >> One interesting thing to try would be replacing it with a regular > > >> non-percpu rwsem and see how it behaves. That should easily tell us > > >> whether this is from actual contention or artifacts from percpu_rwsem > > >> implementation. > > > > > > So, something like the following. Can you please see whether this > > > makes any difference? > > > > Yea. So this brings it down for me closer to what we're seeing with > > the Dmitry's patch reverting the two problematic commits, usually > > 10-50us with one early spike at 18ms. > > So, it's a percpu rwsem issue then. I haven't really followed the > perpcpu rwsem changes closely. Oleg, are multi-milisec delay expected > on down write expected with the current implementation of > percpu_rwsem? There is a synchronize_sched() in there, so sorta. That thing is heavily geared towards readers, as is the only 'sane' choice for global locks. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 20:26 ` Peter Zijlstra @ 2016-07-13 20:39 ` Tejun Heo 2016-07-13 20:51 ` Peter Zijlstra 2016-07-13 20:57 ` John Stultz 2016-07-13 20:52 ` Paul E. McKenney 1 sibling, 2 replies; 67+ messages in thread From: Tejun Heo @ 2016-07-13 20:39 UTC (permalink / raw) To: Peter Zijlstra Cc: John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov, Paul E. McKenney Hello, On Wed, Jul 13, 2016 at 10:26:57PM +0200, Peter Zijlstra wrote: > > So, it's a percpu rwsem issue then. I haven't really followed the > > perpcpu rwsem changes closely. Oleg, are multi-milisec delay expected > > on down write expected with the current implementation of > > percpu_rwsem? > > There is a synchronize_sched() in there, so sorta. That thing is heavily > geared towards readers, as is the only 'sane' choice for global locks. It used to use the expedited variant until 001dac627ff3 ("locking/percpu-rwsem: Make use of the rcu_sync infrastructure"), so it might have been okay before then. Skewing towards readers is fine but tens of millisecs of delays definitely can't fit some use cases. There's a balance between CPU overhead and latency here. If down writes are infrequent enough, it doesn't make sense to aggressively trade off latency for lower processing overhead for some use cases. The options that I can see are 1. Somehow make percpu_rwsem's write behavior more responsive in a way which is acceptable all use cases. This would be great but probably impossible. 2. Add a fast-writer option to percpu_rwsem so that users which care about write latency can opt in for higher processing overhead for lower latency. 3. Implement a custom per-cpu locking construct for the particular use case. #3 would inherently be similar to #2 in its behavior. If #1 isn't possible, #2 looks like the best course of action. Thanks. -- tejun ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 20:39 ` Tejun Heo @ 2016-07-13 20:51 ` Peter Zijlstra 2016-07-13 21:01 ` Tejun Heo ` (2 more replies) 2016-07-13 20:57 ` John Stultz 1 sibling, 3 replies; 67+ messages in thread From: Peter Zijlstra @ 2016-07-13 20:51 UTC (permalink / raw) To: Tejun Heo Cc: John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov, Paul E. McKenney On Wed, Jul 13, 2016 at 04:39:44PM -0400, Tejun Heo wrote: > > There is a synchronize_sched() in there, so sorta. That thing is heavily > > geared towards readers, as is the only 'sane' choice for global locks. > > It used to use the expedited variant until 001dac627ff3 > ("locking/percpu-rwsem: Make use of the rcu_sync infrastructure"), so > it might have been okay before then. Right, but expedited stuff sprays IPIs around the entire system. That's stuff other people complain about. > The options that I can see are > > 1. Somehow make percpu_rwsem's write behavior more responsive in a way > which is acceptable all use cases. This would be great but > probably impossible. > > 2. Add a fast-writer option to percpu_rwsem so that users which care > about write latency can opt in for higher processing overhead for > lower latency. So, IIRC, the trade-off is a full memory barrier in read_lock and read_unlock() vs sync_sched() in write. Full memory barriers are expensive and while the combined cost might well exceed the cost of the sync_sched() it doesn't suffer the latency issues. Not sure if we can frob the two in a single codebase, but I can have a poke if Oleg or Paul doesn't beat me to it. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 20:51 ` Peter Zijlstra @ 2016-07-13 21:01 ` Tejun Heo 2016-07-13 21:03 ` Paul E. McKenney 2016-07-14 13:18 ` Peter Zijlstra 2 siblings, 0 replies; 67+ messages in thread From: Tejun Heo @ 2016-07-13 21:01 UTC (permalink / raw) To: Peter Zijlstra Cc: John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov, Paul E. McKenney On Wed, Jul 13, 2016 at 10:51:02PM +0200, Peter Zijlstra wrote: > On Wed, Jul 13, 2016 at 04:39:44PM -0400, Tejun Heo wrote: > So, IIRC, the trade-off is a full memory barrier in read_lock and > read_unlock() vs sync_sched() in write. > > Full memory barriers are expensive and while the combined cost might > well exceed the cost of the sync_sched() it doesn't suffer the latency > issues. Given the way read side is used for percpu_rwsem, full memory barrier on reader side shouldn't matter at all. The paths are not *that* hot. > Not sure if we can frob the two in a single codebase, but I can have a > poke if Oleg or Paul doesn't beat me to it. At the simplest, it can be rwsem equivalence of lglock. -- tejun ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 20:51 ` Peter Zijlstra 2016-07-13 21:01 ` Tejun Heo @ 2016-07-13 21:03 ` Paul E. McKenney 2016-07-13 21:05 ` Tejun Heo 2016-07-14 13:18 ` Peter Zijlstra 2 siblings, 1 reply; 67+ messages in thread From: Paul E. McKenney @ 2016-07-13 21:03 UTC (permalink / raw) To: Peter Zijlstra Cc: Tejun Heo, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 10:51:02PM +0200, Peter Zijlstra wrote: > On Wed, Jul 13, 2016 at 04:39:44PM -0400, Tejun Heo wrote: > > > > There is a synchronize_sched() in there, so sorta. That thing is heavily > > > geared towards readers, as is the only 'sane' choice for global locks. > > > > It used to use the expedited variant until 001dac627ff3 > > ("locking/percpu-rwsem: Make use of the rcu_sync infrastructure"), so > > it might have been okay before then. > > Right, but expedited stuff sprays IPIs around the entire system. That's > stuff other people complain about. Do anyone other than the non-NO_HZ_FULL low-latency guys and the -rt guys care? > > The options that I can see are > > > > 1. Somehow make percpu_rwsem's write behavior more responsive in a way > > which is acceptable all use cases. This would be great but > > probably impossible. > > > > 2. Add a fast-writer option to percpu_rwsem so that users which care > > about write latency can opt in for higher processing overhead for > > lower latency. > > So, IIRC, the trade-off is a full memory barrier in read_lock and > read_unlock() vs sync_sched() in write. > > Full memory barriers are expensive and while the combined cost might > well exceed the cost of the sync_sched() it doesn't suffer the latency > issues. > > Not sure if we can frob the two in a single codebase, but I can have a > poke if Oleg or Paul doesn't beat me to it. Take the patch that I just sent out and make the choice of normal vs. expedited depend on CONFIG_PREEMPT_RT or whatever the -rt guys are calling it these days. Is there a low-latency Kconfig option other than CONFIG_NO_HZ_FULL? The memory-barrier approach can definitely be made to work, but is going to be more complex due to the need to wait for readers. Thanx, Paul ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 21:03 ` Paul E. McKenney @ 2016-07-13 21:05 ` Tejun Heo 2016-07-13 21:18 ` Paul E. McKenney 0 siblings, 1 reply; 67+ messages in thread From: Tejun Heo @ 2016-07-13 21:05 UTC (permalink / raw) To: Paul E. McKenney Cc: Peter Zijlstra, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 02:03:15PM -0700, Paul E. McKenney wrote: > Take the patch that I just sent out and make the choice of normal > vs. expedited depend on CONFIG_PREEMPT_RT or whatever the -rt guys are > calling it these days. Is there a low-latency Kconfig option other > than CONFIG_NO_HZ_FULL? Sounds like a plan to me. Thanks. -- tejun ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 21:05 ` Tejun Heo @ 2016-07-13 21:18 ` Paul E. McKenney 2016-07-13 21:42 ` Paul E. McKenney 2016-07-13 22:01 ` Tejun Heo 0 siblings, 2 replies; 67+ messages in thread From: Paul E. McKenney @ 2016-07-13 21:18 UTC (permalink / raw) To: Tejun Heo Cc: Peter Zijlstra, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 05:05:26PM -0400, Tejun Heo wrote: > On Wed, Jul 13, 2016 at 02:03:15PM -0700, Paul E. McKenney wrote: > > Take the patch that I just sent out and make the choice of normal > > vs. expedited depend on CONFIG_PREEMPT_RT or whatever the -rt guys are > > calling it these days. Is there a low-latency Kconfig option other > > than CONFIG_NO_HZ_FULL? > > Sounds like a plan to me. I like the way we like each other's idea. Mutually assured laziness? ;-) Thanx, Paul ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 21:18 ` Paul E. McKenney @ 2016-07-13 21:42 ` Paul E. McKenney 2016-07-13 21:46 ` John Stultz 2016-07-13 22:25 ` John Stultz 2016-07-13 22:01 ` Tejun Heo 1 sibling, 2 replies; 67+ messages in thread From: Paul E. McKenney @ 2016-07-13 21:42 UTC (permalink / raw) To: Tejun Heo Cc: Peter Zijlstra, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 02:18:41PM -0700, Paul E. McKenney wrote: > On Wed, Jul 13, 2016 at 05:05:26PM -0400, Tejun Heo wrote: > > On Wed, Jul 13, 2016 at 02:03:15PM -0700, Paul E. McKenney wrote: > > > Take the patch that I just sent out and make the choice of normal > > > vs. expedited depend on CONFIG_PREEMPT_RT or whatever the -rt guys are > > > calling it these days. Is there a low-latency Kconfig option other > > > than CONFIG_NO_HZ_FULL? > > > > Sounds like a plan to me. > > I like the way we like each other's idea. Mutually assured laziness? ;-) But here is what mine might look like. Untested, probably does not even build. Note that the default is -no- expediting, use the rcusync.expedited kernel parameter to enable it. Thanx, Paul ------------------------------------------------------------------------ diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 82b42c958d1c..b8bc9854e548 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3229,6 +3229,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. energy efficiency by requiring that the kthreads periodically wake up to do the polling. + rcusync.expedited [KNL] + Specify that the rcusync mechanism use expedited + grace periods. As of mid-2016, this affects + per-CPU rwsems. + rcutree.blimit= [KNL] Set maximum number of finished RCU callbacks to process in one batch. diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c index be922c9f3d37..5bc5bef2e00a 100644 --- a/kernel/rcu/sync.c +++ b/kernel/rcu/sync.c @@ -22,6 +22,14 @@ #include <linux/rcu_sync.h> #include <linux/sched.h> +#include <linux/moduleparam.h> +#include <linux/module.h> + +MODULE_ALIAS("rcusync"); +#ifdef MODULE_PARAM_PREFIX +#undef MODULE_PARAM_PREFIX +#endif +#define MODULE_PARAM_PREFIX "rcusync." #ifdef CONFIG_PROVE_RCU #define __INIT_HELD(func) .held = func, @@ -29,7 +37,7 @@ #define __INIT_HELD(func) #endif -static const struct { +static struct { void (*sync)(void); void (*call)(struct rcu_head *, void (*)(struct rcu_head *)); void (*wait)(void); @@ -62,6 +70,20 @@ enum { CB_IDLE = 0, CB_PENDING, CB_REPLAY }; #define rss_lock gp_wait.lock +static bool expedited; +module_param(expedited, bool, 0444); + +static int __init rcu_sync_early_init(void) +{ + if (expedited) { + gp_ops[RCU_SYNC].sync = synchronize_rcu_expedited; + gp_ops[RCU_SCHED_SYNC].sync = synchronize_sched_expedited; + gp_ops[RCU_BH_SYNC].sync = synchronize_rcu_bh_expedited; + } + return 0; +} +early_initcall(rcu_sync_early_init); + #ifdef CONFIG_PROVE_RCU void rcu_sync_lockdep_assert(struct rcu_sync *rsp) { ^ permalink raw reply related [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 21:42 ` Paul E. McKenney @ 2016-07-13 21:46 ` John Stultz 2016-07-13 22:17 ` Paul E. McKenney 2016-07-13 22:25 ` John Stultz 1 sibling, 1 reply; 67+ messages in thread From: John Stultz @ 2016-07-13 21:46 UTC (permalink / raw) To: Paul McKenney Cc: Tejun Heo, Peter Zijlstra, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 2:42 PM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > On Wed, Jul 13, 2016 at 02:18:41PM -0700, Paul E. McKenney wrote: >> On Wed, Jul 13, 2016 at 05:05:26PM -0400, Tejun Heo wrote: >> > On Wed, Jul 13, 2016 at 02:03:15PM -0700, Paul E. McKenney wrote: >> > > Take the patch that I just sent out and make the choice of normal >> > > vs. expedited depend on CONFIG_PREEMPT_RT or whatever the -rt guys are >> > > calling it these days. Is there a low-latency Kconfig option other >> > > than CONFIG_NO_HZ_FULL? >> > >> > Sounds like a plan to me. >> >> I like the way we like each other's idea. Mutually assured laziness? ;-) > > But here is what mine might look like. Untested, probably does > not even build. Note that the default is -no- expediting, use the > rcusync.expedited kernel parameter to enable it. I was working on something similar, but using a config option. Would adding a config option for the default make sense here, since I'd probably prefer to have one less thing to always specify on the cmdline? thanks -john ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 21:46 ` John Stultz @ 2016-07-13 22:17 ` Paul E. McKenney 2016-07-13 22:39 ` John Stultz 0 siblings, 1 reply; 67+ messages in thread From: Paul E. McKenney @ 2016-07-13 22:17 UTC (permalink / raw) To: John Stultz Cc: Tejun Heo, Peter Zijlstra, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 02:46:37PM -0700, John Stultz wrote: > On Wed, Jul 13, 2016 at 2:42 PM, Paul E. McKenney > <paulmck@linux.vnet.ibm.com> wrote: > > On Wed, Jul 13, 2016 at 02:18:41PM -0700, Paul E. McKenney wrote: > >> On Wed, Jul 13, 2016 at 05:05:26PM -0400, Tejun Heo wrote: > >> > On Wed, Jul 13, 2016 at 02:03:15PM -0700, Paul E. McKenney wrote: > >> > > Take the patch that I just sent out and make the choice of normal > >> > > vs. expedited depend on CONFIG_PREEMPT_RT or whatever the -rt guys are > >> > > calling it these days. Is there a low-latency Kconfig option other > >> > > than CONFIG_NO_HZ_FULL? > >> > > >> > Sounds like a plan to me. > >> > >> I like the way we like each other's idea. Mutually assured laziness? ;-) > > > > But here is what mine might look like. Untested, probably does > > not even build. Note that the default is -no- expediting, use the > > rcusync.expedited kernel parameter to enable it. > > I was working on something similar, but using a config option. Would > adding a config option for the default make sense here, since I'd > probably prefer to have one less thing to always specify on the > cmdline? As long as you don't mind it depending on CONFIG_RCU_EXPERT, no problem. Perhaps like the following, on top of the previous patch? Or if you are going to put it in defconfig files only, I can make it so that it isn't changeable at menuconfig time. Thanx, Paul ------------------------------------------------------------------------ commit 57d8274b6906fad135a74beb59d4a99552659686 Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Date: Wed Jul 13 15:13:31 2016 -0700 rcu: Provide RCUSYNC_EXPEDITE option for rcusync.expedited default This commit provides an RCUSYNC_EXPEDITE Kconfig option that specifies the default value for the rcusync.expedited kernel parameter. This makes it easier to use rcusync.expedited functionality in cases where specifying kernel boot parameters should be avoided. Reported-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> diff --git a/init/Kconfig b/init/Kconfig index a068265fbcaf..de548d6ff82b 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -782,6 +782,23 @@ config RCU_EXPEDITE_BOOT Accept the default if unsure. +config RCUSYNC_EXPEDITE + bool "Expedite rcusync operations for per-CPU rwsems" + depends on RCU_EXPERT + default n + help + Use this option to speed up per-CPU rwsem operations that are + in turn used by some cgroups operations. However, note well + that specifying this option will enable expedited RCU grace + periods. These expedited grace periods can in turn introduce + OS jitter, which can interfere with real-time, low-latency, + HPC, and userspace-polling RDMA workloads. That said, this + OS jitter will not affect CPUs that are in nohz_full mode for + the duration of the per-CPU rwsem operation in question. + + Say Y here if you want fast cgroups at the expense of OS jitter. + Say N here if you are unsure. + endmenu # "RCU Subsystem" config BUILD_BIN2C diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c index 5bc5bef2e00a..58c594b41d48 100644 --- a/kernel/rcu/sync.c +++ b/kernel/rcu/sync.c @@ -70,7 +70,7 @@ enum { CB_IDLE = 0, CB_PENDING, CB_REPLAY }; #define rss_lock gp_wait.lock -static bool expedited; +static bool expedited = IS_ENABLED(CONFIG_RCUSYNC_EXPEDITE); module_param(expedited, bool, 0444); static int __init rcu_sync_early_init(void) ^ permalink raw reply related [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 22:17 ` Paul E. McKenney @ 2016-07-13 22:39 ` John Stultz 2016-07-13 23:02 ` Paul E. McKenney 0 siblings, 1 reply; 67+ messages in thread From: John Stultz @ 2016-07-13 22:39 UTC (permalink / raw) To: Paul McKenney Cc: Tejun Heo, Peter Zijlstra, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 3:17 PM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > On Wed, Jul 13, 2016 at 02:46:37PM -0700, John Stultz wrote: >> On Wed, Jul 13, 2016 at 2:42 PM, Paul E. McKenney >> <paulmck@linux.vnet.ibm.com> wrote: >> > On Wed, Jul 13, 2016 at 02:18:41PM -0700, Paul E. McKenney wrote: >> >> On Wed, Jul 13, 2016 at 05:05:26PM -0400, Tejun Heo wrote: >> >> > On Wed, Jul 13, 2016 at 02:03:15PM -0700, Paul E. McKenney wrote: >> >> > > Take the patch that I just sent out and make the choice of normal >> >> > > vs. expedited depend on CONFIG_PREEMPT_RT or whatever the -rt guys are >> >> > > calling it these days. Is there a low-latency Kconfig option other >> >> > > than CONFIG_NO_HZ_FULL? >> >> > >> >> > Sounds like a plan to me. >> >> >> >> I like the way we like each other's idea. Mutually assured laziness? ;-) >> > >> > But here is what mine might look like. Untested, probably does >> > not even build. Note that the default is -no- expediting, use the >> > rcusync.expedited kernel parameter to enable it. >> >> I was working on something similar, but using a config option. Would >> adding a config option for the default make sense here, since I'd >> probably prefer to have one less thing to always specify on the >> cmdline? > > As long as you don't mind it depending on CONFIG_RCU_EXPERT, no problem. > > Perhaps like the following, on top of the previous patch? > > Or if you are going to put it in defconfig files only, I can make it > so that it isn't changeable at menuconfig time. I think having it discoverable via menuconfig is useful, and I've got no objections to it being under RCU_EXPERT (assuming I don't badly muck up my RCU settings accidentally :). I only had that one nit about maybe wanting to put something in dmesg when we're using the expedited methods. But otherwise both patches look great and are working well! Do you mind marking them both for stable 4.4+? Tested-by: John Stultz <john.stultz@linaro.org> Acked-by: John Stultz <john.stultz@linaro.org> Also, do make sure Dmitry gets the reported-by credit for the first patch. thanks -john ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 22:39 ` John Stultz @ 2016-07-13 23:02 ` Paul E. McKenney 2016-07-13 23:04 ` Paul E. McKenney 2016-07-14 16:54 ` John Stultz 0 siblings, 2 replies; 67+ messages in thread From: Paul E. McKenney @ 2016-07-13 23:02 UTC (permalink / raw) To: John Stultz Cc: Tejun Heo, Peter Zijlstra, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 03:39:37PM -0700, John Stultz wrote: > On Wed, Jul 13, 2016 at 3:17 PM, Paul E. McKenney > <paulmck@linux.vnet.ibm.com> wrote: > > On Wed, Jul 13, 2016 at 02:46:37PM -0700, John Stultz wrote: > >> On Wed, Jul 13, 2016 at 2:42 PM, Paul E. McKenney > >> <paulmck@linux.vnet.ibm.com> wrote: > >> > On Wed, Jul 13, 2016 at 02:18:41PM -0700, Paul E. McKenney wrote: > >> >> On Wed, Jul 13, 2016 at 05:05:26PM -0400, Tejun Heo wrote: > >> >> > On Wed, Jul 13, 2016 at 02:03:15PM -0700, Paul E. McKenney wrote: > >> >> > > Take the patch that I just sent out and make the choice of normal > >> >> > > vs. expedited depend on CONFIG_PREEMPT_RT or whatever the -rt guys are > >> >> > > calling it these days. Is there a low-latency Kconfig option other > >> >> > > than CONFIG_NO_HZ_FULL? > >> >> > > >> >> > Sounds like a plan to me. > >> >> > >> >> I like the way we like each other's idea. Mutually assured laziness? ;-) > >> > > >> > But here is what mine might look like. Untested, probably does > >> > not even build. Note that the default is -no- expediting, use the > >> > rcusync.expedited kernel parameter to enable it. > >> > >> I was working on something similar, but using a config option. Would > >> adding a config option for the default make sense here, since I'd > >> probably prefer to have one less thing to always specify on the > >> cmdline? > > > > As long as you don't mind it depending on CONFIG_RCU_EXPERT, no problem. > > > > Perhaps like the following, on top of the previous patch? > > > > Or if you are going to put it in defconfig files only, I can make it > > so that it isn't changeable at menuconfig time. > > I think having it discoverable via menuconfig is useful, and I've got > no objections to it being under RCU_EXPERT > (assuming I don't badly muck up my RCU settings accidentally :). But isn't mucking up your RCU settings half of the fun? ;-) > I only had that one nit about maybe wanting to put something in dmesg > when we're using the expedited methods. Updated, please see below. > But otherwise both patches look great and are working well! > > Do you mind marking them both for stable 4.4+? OK, looks like it does qualify in the "fix a notable performance or interactivity issue" category. > Tested-by: John Stultz <john.stultz@linaro.org> > Acked-by: John Stultz <john.stultz@linaro.org> > > Also, do make sure Dmitry gets the reported-by credit for the first patch. Done! The updated first patch is below, and the second will follow. Thanx, Paul ------------------------------------------------------------------------ commit 59435eb836ee73b30ed6ada525125b67b4029321 Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Date: Wed Jul 13 14:43:46 2016 -0700 rcu: Provide rcusync.expedited kernel boot parameter Dmitry Shmidt and John Stultz noticed that __cgroup_procs_write() sometimes incurred excessive overheads, ranging up into the tens of milliseconds. Further testing confirmed speculation that this was due to synchronize_sched() within rcusync being invoked by per-CPU rwsems. This testing also showed that substituting synchronize_sched_expedited() for synchronize_sched() greatly reduced the overheads to below 200 microseconds, with the occasional excursion into the low single digits worth of milliseconds. This commit therefore provides a rcusync.expedited kernel boot parameter that causes rcusync to use expedited grace-period primitives. Reported-by: Dmitry Shmidt <dimitrysh@google.com> Reported-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Tested-by: John Stultz <john.stultz@linaro.org> Acked-by: John Stultz <john.stultz@linaro.org> Cc: <stable@vger.kernel.org> # 4.4.x- diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 82b42c958d1c..b8bc9854e548 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3229,6 +3229,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. energy efficiency by requiring that the kthreads periodically wake up to do the polling. + rcusync.expedited [KNL] + Specify that the rcusync mechanism use expedited + grace periods. As of mid-2016, this affects + per-CPU rwsems. + rcutree.blimit= [KNL] Set maximum number of finished RCU callbacks to process in one batch. diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c index be922c9f3d37..0d0dc992cce7 100644 --- a/kernel/rcu/sync.c +++ b/kernel/rcu/sync.c @@ -22,6 +22,14 @@ #include <linux/rcu_sync.h> #include <linux/sched.h> +#include <linux/moduleparam.h> +#include <linux/module.h> + +MODULE_ALIAS("rcusync"); +#ifdef MODULE_PARAM_PREFIX +#undef MODULE_PARAM_PREFIX +#endif +#define MODULE_PARAM_PREFIX "rcusync." #ifdef CONFIG_PROVE_RCU #define __INIT_HELD(func) .held = func, @@ -29,14 +37,14 @@ #define __INIT_HELD(func) #endif -static const struct { +static struct { void (*sync)(void); void (*call)(struct rcu_head *, void (*)(struct rcu_head *)); void (*wait)(void); #ifdef CONFIG_PROVE_RCU int (*held)(void); #endif -} gp_ops[] = { +} gp_ops[] __read_mostly = { [RCU_SYNC] = { .sync = synchronize_rcu, .call = call_rcu, @@ -62,6 +70,21 @@ enum { CB_IDLE = 0, CB_PENDING, CB_REPLAY }; #define rss_lock gp_wait.lock +static bool expedited; +module_param(expedited, bool, 0444); + +static int __init rcu_sync_early_init(void) +{ + if (expedited) { + pr_info("RCU_SYNC: Expedited operation in effect.\n"); + gp_ops[RCU_SYNC].sync = synchronize_rcu_expedited; + gp_ops[RCU_SCHED_SYNC].sync = synchronize_sched_expedited; + gp_ops[RCU_BH_SYNC].sync = synchronize_rcu_bh_expedited; + } + return 0; +} +early_initcall(rcu_sync_early_init); + #ifdef CONFIG_PROVE_RCU void rcu_sync_lockdep_assert(struct rcu_sync *rsp) { ^ permalink raw reply related [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 23:02 ` Paul E. McKenney @ 2016-07-13 23:04 ` Paul E. McKenney 2016-07-14 11:35 ` Tejun Heo 2016-07-14 16:54 ` John Stultz 1 sibling, 1 reply; 67+ messages in thread From: Paul E. McKenney @ 2016-07-13 23:04 UTC (permalink / raw) To: John Stultz Cc: Tejun Heo, Peter Zijlstra, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 04:02:38PM -0700, Paul E. McKenney wrote: > On Wed, Jul 13, 2016 at 03:39:37PM -0700, John Stultz wrote: > > On Wed, Jul 13, 2016 at 3:17 PM, Paul E. McKenney > > <paulmck@linux.vnet.ibm.com> wrote: > > > On Wed, Jul 13, 2016 at 02:46:37PM -0700, John Stultz wrote: > > >> On Wed, Jul 13, 2016 at 2:42 PM, Paul E. McKenney > > >> <paulmck@linux.vnet.ibm.com> wrote: > > >> > On Wed, Jul 13, 2016 at 02:18:41PM -0700, Paul E. McKenney wrote: > > >> >> On Wed, Jul 13, 2016 at 05:05:26PM -0400, Tejun Heo wrote: > > >> >> > On Wed, Jul 13, 2016 at 02:03:15PM -0700, Paul E. McKenney wrote: > > >> >> > > Take the patch that I just sent out and make the choice of normal > > >> >> > > vs. expedited depend on CONFIG_PREEMPT_RT or whatever the -rt guys are > > >> >> > > calling it these days. Is there a low-latency Kconfig option other > > >> >> > > than CONFIG_NO_HZ_FULL? > > >> >> > > > >> >> > Sounds like a plan to me. > > >> >> > > >> >> I like the way we like each other's idea. Mutually assured laziness? ;-) > > >> > > > >> > But here is what mine might look like. Untested, probably does > > >> > not even build. Note that the default is -no- expediting, use the > > >> > rcusync.expedited kernel parameter to enable it. > > >> > > >> I was working on something similar, but using a config option. Would > > >> adding a config option for the default make sense here, since I'd > > >> probably prefer to have one less thing to always specify on the > > >> cmdline? > > > > > > As long as you don't mind it depending on CONFIG_RCU_EXPERT, no problem. > > > > > > Perhaps like the following, on top of the previous patch? > > > > > > Or if you are going to put it in defconfig files only, I can make it > > > so that it isn't changeable at menuconfig time. > > > > I think having it discoverable via menuconfig is useful, and I've got > > no objections to it being under RCU_EXPERT > > (assuming I don't badly muck up my RCU settings accidentally :). > > But isn't mucking up your RCU settings half of the fun? ;-) > > > I only had that one nit about maybe wanting to put something in dmesg > > when we're using the expedited methods. > > Updated, please see below. > > > But otherwise both patches look great and are working well! > > > > Do you mind marking them both for stable 4.4+? > > OK, looks like it does qualify in the "fix a notable performance or > interactivity issue" category. > > > Tested-by: John Stultz <john.stultz@linaro.org> > > Acked-by: John Stultz <john.stultz@linaro.org> > > > > Also, do make sure Dmitry gets the reported-by credit for the first patch. > > Done! The updated first patch is below, and the second will follow. As promised/threatened... Thanx, Paul ------------------------------------------------------------------------ commit b4edebb8f5664a3a51be1e3ff3d7f1cb2d3d5c88 Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Date: Wed Jul 13 15:13:31 2016 -0700 rcu: Provide RCUSYNC_EXPEDITE option for rcusync.expedited default This commit provides an RCUSYNC_EXPEDITE Kconfig option that specifies the default value for the rcusync.expedited kernel parameter. This makes it easier to use rcusync.expedited functionality in cases where specifying kernel boot parameters should be avoided. Reported-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Tested-by: John Stultz <john.stultz@linaro.org> Acked-by: John Stultz <john.stultz@linaro.org> Cc: <stable@vger.kernel.org> # 4.4.x- diff --git a/init/Kconfig b/init/Kconfig index a068265fbcaf..de548d6ff82b 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -782,6 +782,23 @@ config RCU_EXPEDITE_BOOT Accept the default if unsure. +config RCUSYNC_EXPEDITE + bool "Expedite rcusync operations for per-CPU rwsems" + depends on RCU_EXPERT + default n + help + Use this option to speed up per-CPU rwsem operations that are + in turn used by some cgroups operations. However, note well + that specifying this option will enable expedited RCU grace + periods. These expedited grace periods can in turn introduce + OS jitter, which can interfere with real-time, low-latency, + HPC, and userspace-polling RDMA workloads. That said, this + OS jitter will not affect CPUs that are in nohz_full mode for + the duration of the per-CPU rwsem operation in question. + + Say Y here if you want fast cgroups at the expense of OS jitter. + Say N here if you are unsure. + endmenu # "RCU Subsystem" config BUILD_BIN2C diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c index 0d0dc992cce7..cc75d5071543 100644 --- a/kernel/rcu/sync.c +++ b/kernel/rcu/sync.c @@ -70,7 +70,7 @@ enum { CB_IDLE = 0, CB_PENDING, CB_REPLAY }; #define rss_lock gp_wait.lock -static bool expedited; +static bool expedited = IS_ENABLED(CONFIG_RCUSYNC_EXPEDITE); module_param(expedited, bool, 0444); static int __init rcu_sync_early_init(void) ^ permalink raw reply related [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 23:04 ` Paul E. McKenney @ 2016-07-14 11:35 ` Tejun Heo 2016-07-14 12:04 ` Peter Zijlstra 0 siblings, 1 reply; 67+ messages in thread From: Tejun Heo @ 2016-07-14 11:35 UTC (permalink / raw) To: Paul E. McKenney Cc: John Stultz, Peter Zijlstra, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov Hello, On Wed, Jul 13, 2016 at 04:04:04PM -0700, Paul E. McKenney wrote: > commit b4edebb8f5664a3a51be1e3ff3d7f1cb2d3d5c88 > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > Date: Wed Jul 13 15:13:31 2016 -0700 > > rcu: Provide RCUSYNC_EXPEDITE option for rcusync.expedited default > > This commit provides an RCUSYNC_EXPEDITE Kconfig option that specifies > the default value for the rcusync.expedited kernel parameter. This > makes it easier to use rcusync.expedited functionality in cases where > specifying kernel boot parameters should be avoided. > > Reported-by: John Stultz <john.stultz@linaro.org> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > Tested-by: John Stultz <john.stultz@linaro.org> > Acked-by: John Stultz <john.stultz@linaro.org> > Cc: <stable@vger.kernel.org> # 4.4.x- I think it probably makes sense to make this the default on !RT at least with a separate patch w/o stable cc'd. While most use cases will be fine with the latency on write path, it also means that the reader side is blocked for the duration which can hurt. rwsem implies a lot more readers and thus more read lock operations than writes. It's weird to trade off higher latency for lower cpu usage when it would also slow down all readers. Thanks. -- tejun ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 11:35 ` Tejun Heo @ 2016-07-14 12:04 ` Peter Zijlstra 2016-07-14 12:08 ` Tejun Heo 0 siblings, 1 reply; 67+ messages in thread From: Peter Zijlstra @ 2016-07-14 12:04 UTC (permalink / raw) To: Tejun Heo Cc: Paul E. McKenney, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Thu, Jul 14, 2016 at 07:35:05AM -0400, Tejun Heo wrote: > Hello, > > On Wed, Jul 13, 2016 at 04:04:04PM -0700, Paul E. McKenney wrote: > > commit b4edebb8f5664a3a51be1e3ff3d7f1cb2d3d5c88 > > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > Date: Wed Jul 13 15:13:31 2016 -0700 > > > > rcu: Provide RCUSYNC_EXPEDITE option for rcusync.expedited default > > > > This commit provides an RCUSYNC_EXPEDITE Kconfig option that specifies > > the default value for the rcusync.expedited kernel parameter. This > > makes it easier to use rcusync.expedited functionality in cases where > > specifying kernel boot parameters should be avoided. > > > > Reported-by: John Stultz <john.stultz@linaro.org> > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > Tested-by: John Stultz <john.stultz@linaro.org> > > Acked-by: John Stultz <john.stultz@linaro.org> > > Cc: <stable@vger.kernel.org> # 4.4.x- > > I think it probably makes sense to make this the default on !RT at > least with a separate patch w/o stable cc'd. While most use cases > will be fine with the latency on write path, it also means that the > reader side is blocked for the duration which can hurt. rwsem implies > a lot more readers and thus more read lock operations than writes. > It's weird to trade off higher latency for lower cpu usage when it > would also slow down all readers. NAK, no expedited muck by default. There's more than just RT that doesn't like IPI sprays. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 12:04 ` Peter Zijlstra @ 2016-07-14 12:08 ` Tejun Heo 2016-07-14 12:20 ` Peter Zijlstra 0 siblings, 1 reply; 67+ messages in thread From: Tejun Heo @ 2016-07-14 12:08 UTC (permalink / raw) To: Peter Zijlstra Cc: Paul E. McKenney, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Thu, Jul 14, 2016 at 02:04:28PM +0200, Peter Zijlstra wrote: > > I think it probably makes sense to make this the default on !RT at > > least with a separate patch w/o stable cc'd. While most use cases > > will be fine with the latency on write path, it also means that the > > reader side is blocked for the duration which can hurt. rwsem implies > > a lot more readers and thus more read lock operations than writes. > > It's weird to trade off higher latency for lower cpu usage when it > > would also slow down all readers. > > NAK, no expedited muck by default. There's more than just RT that > doesn't like IPI sprays. Can you elaborate? If that's the case, we have the wrong implemention for percpu-rwsem where very long delays for writers induce the same level of delays to all readers. If expedited by default isn't workable, we should move away from rcu_sync for percpu_rwsem. Thanks. -- tejun ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 12:08 ` Tejun Heo @ 2016-07-14 12:20 ` Peter Zijlstra 2016-07-14 15:07 ` Tejun Heo 0 siblings, 1 reply; 67+ messages in thread From: Peter Zijlstra @ 2016-07-14 12:20 UTC (permalink / raw) To: Tejun Heo Cc: Paul E. McKenney, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Thu, Jul 14, 2016 at 08:08:45AM -0400, Tejun Heo wrote: > On Thu, Jul 14, 2016 at 02:04:28PM +0200, Peter Zijlstra wrote: > > > I think it probably makes sense to make this the default on !RT at > > > least with a separate patch w/o stable cc'd. While most use cases > > > will be fine with the latency on write path, it also means that the > > > reader side is blocked for the duration which can hurt. rwsem implies > > > a lot more readers and thus more read lock operations than writes. > > > It's weird to trade off higher latency for lower cpu usage when it > > > would also slow down all readers. > > > > NAK, no expedited muck by default. There's more than just RT that > > doesn't like IPI sprays. > > Can you elaborate? HPC doesn't use RT but still wants to minimize jitter such that all CPUs complete their work ASAP. They use barriers to wait on the slowest CPU to complete work. Sending random interrupts disturbs cache and other stuff and delays things unnecessarily. Same with RDMA (or other) userspace poll loops which want minimal latency, they too don't use RT, but also very much want to avoid the kernel poking at them. Many of this could eventually use NOHZ_FULL, but I'm not sure all of that is suitable. In general its very bad form to spray interrupts just because and we've spend a lot of effort to reduce that. > If that's the case, we have the wrong implemention > for percpu-rwsem where very long delays for writers induce the same > level of delays to all readers. If expedited by default isn't > workable, we should move away from rcu_sync for percpu_rwsem. Just because your usecase doesn't like it, doesn't mean its not good. Its a perfectly fine implementation for uprobes for example. The addition/removal of uprobes is extremely rare, as global writers should be. And no, the writer delay isn't observed by the readers, those will continue 'undisturbed' for most of it. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 12:20 ` Peter Zijlstra @ 2016-07-14 15:07 ` Tejun Heo 2016-07-14 15:24 ` Tejun Heo 2016-07-14 16:32 ` Peter Zijlstra 0 siblings, 2 replies; 67+ messages in thread From: Tejun Heo @ 2016-07-14 15:07 UTC (permalink / raw) To: Peter Zijlstra Cc: Paul E. McKenney, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Thu, Jul 14, 2016 at 02:20:49PM +0200, Peter Zijlstra wrote: > > If that's the case, we have the wrong implemention > > for percpu-rwsem where very long delays for writers induce the same > > level of delays to all readers. If expedited by default isn't > > workable, we should move away from rcu_sync for percpu_rwsem. > > Just because your usecase doesn't like it, doesn't mean its not good. > Its a perfectly fine implementation for uprobes for example. The > addition/removal of uprobes is extremely rare, as global writers should > be. > > And no, the writer delay isn't observed by the readers, those will > continue 'undisturbed' for most of it. How? While write lock is pending, no new reader is allowed. If reader ops are high frequency, they will surely get affected. It just isn't a good design to inject RCU grace period synchronously into a hot path. Thanks. -- tejun ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 15:07 ` Tejun Heo @ 2016-07-14 15:24 ` Tejun Heo 2016-07-14 16:32 ` Peter Zijlstra 1 sibling, 0 replies; 67+ messages in thread From: Tejun Heo @ 2016-07-14 15:24 UTC (permalink / raw) To: Peter Zijlstra Cc: Paul E. McKenney, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Thu, Jul 14, 2016 at 11:07:15AM -0400, Tejun Heo wrote: > On Thu, Jul 14, 2016 at 02:20:49PM +0200, Peter Zijlstra wrote: > > > If that's the case, we have the wrong implemention > > > for percpu-rwsem where very long delays for writers induce the same > > > level of delays to all readers. If expedited by default isn't > > > workable, we should move away from rcu_sync for percpu_rwsem. > > > > Just because your usecase doesn't like it, doesn't mean its not good. > > Its a perfectly fine implementation for uprobes for example. The > > addition/removal of uprobes is extremely rare, as global writers should > > be. > > > > And no, the writer delay isn't observed by the readers, those will > > continue 'undisturbed' for most of it. > > How? While write lock is pending, no new reader is allowed. If > reader ops are high frequency, they will surely get affected. It just > isn't a good design to inject RCU grace period synchronously into a > hot path. Oops, right, the grace period is just used to switch the lock to global mode while readers are passing through. Never mind this point. It's purely about writer latency then. Thanks. -- tejun ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 15:07 ` Tejun Heo 2016-07-14 15:24 ` Tejun Heo @ 2016-07-14 16:32 ` Peter Zijlstra 2016-07-14 17:34 ` Oleg Nesterov 1 sibling, 1 reply; 67+ messages in thread From: Peter Zijlstra @ 2016-07-14 16:32 UTC (permalink / raw) To: Tejun Heo Cc: Paul E. McKenney, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Thu, Jul 14, 2016 at 11:07:15AM -0400, Tejun Heo wrote: > How? While write lock is pending, no new reader is allowed. Look at the new percpu_down_write (the old one is similar in concept): + void percpu_down_write(struct percpu_rw_semaphore *sem) + { + down_write(&sem->rw_sem); + + /* Notify readers to take the slow path. */ + rcu_sync_enter(&sem->rss); + + /* + * Notify new readers to block; up until now, and thus throughout the + * longish rcu_sync_enter() above, new readers could still come in. + */ + WRITE_ONCE(sem->state, readers_block); Note how up until this point new readers could happen? So the 'entire' synchronize_sched() call is 'invisible' to new readers. We need the sync_sched() to ensure all new down_read callers will go through the 'slow' down_read path and even look at sem->state. + + smp_mb(); /* D matches A */ + + /* + * If they don't see our writer of readers_block to sem->state, + * then we are guaranteed to see their sem->refcount increment, and + * therefore will wait for them. + */ + + /* Wait for all now active readers to complete. */ + wait_event(sem->writer, readers_active_check(sem)); + } > If reader ops are high frequency, they will surely get affected. Before the sync_sched() a down_read (PREEMPT=n, LOCKDEP=n) is basically: __this_cpu_inc(*sem->refcount) if (sem->rss->gp_state) /* false */ ; This is one purely local (!atomic) RmW and one load of a shared variable. Absolute minimal overhead. During sync_sched() gp_state is !0 and we end up doing: __this_cpu_inc(*sem->refcount) if (sem->rss->gp_state) { smp_mb(); if (sem->state != readers_block) /* true */ return; } Which is 1 smp_mb() and 1 shared state load (to the same cacheline we touched before IIRC) more. Now full barriers are really rather expensive, and do show up on profiles. (and this is where the old and new code differ, the old code would end up doing: __down_read(&sem->rwsem), which is a shared atomic RmW and is _much_ more expensive). > It just isn't a good design to inject RCU grace period synchronously > into a hot path. That's just the point, the write side of a _global_ lock can never, per definition, be a hot path. Now, I realize not everyone wants these same tradeoffs and I did you this patch to allow that. But I really think that this Android usecase invalidates the premise of cgroups using a global lock. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 16:32 ` Peter Zijlstra @ 2016-07-14 17:34 ` Oleg Nesterov 0 siblings, 0 replies; 67+ messages in thread From: Oleg Nesterov @ 2016-07-14 17:34 UTC (permalink / raw) To: Peter Zijlstra Cc: Tejun Heo, Paul E. McKenney, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos On 07/14, Peter Zijlstra wrote: > > But I really think that this Android usecase invalidates the premise of > cgroups using a global lock. Perhaps... but it would be nice to have a global lock for cgroups (and in fact probably unify it with dup_mmap_sem). And we can't simply revert that change now. I am wondering if this use-case is really Android-specific or not. Because, once again, we can add a boot option or even run-time knob for cgroup_threadgroup_rwsem. If it is really Android-specific, we do not want to penalize fork/exit by default. Oleg. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 23:02 ` Paul E. McKenney 2016-07-13 23:04 ` Paul E. McKenney @ 2016-07-14 16:54 ` John Stultz 1 sibling, 0 replies; 67+ messages in thread From: John Stultz @ 2016-07-14 16:54 UTC (permalink / raw) To: Paul McKenney Cc: Tejun Heo, Peter Zijlstra, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 4:02 PM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > On Wed, Jul 13, 2016 at 03:39:37PM -0700, John Stultz wrote: >> >> But otherwise both patches look great and are working well! >> >> Do you mind marking them both for stable 4.4+? > > OK, looks like it does qualify in the "fix a notable performance or > interactivity issue" category. > >> Tested-by: John Stultz <john.stultz@linaro.org> >> Acked-by: John Stultz <john.stultz@linaro.org> >> >> Also, do make sure Dmitry gets the reported-by credit for the first patch. > > Done! The updated first patch is below, and the second will follow. So just as a heads up, while this patch *greatly* improved the situation, apparently the occasional 7ms spikes (again, much better then 80ms!) still seen are causing trouble when compared w/ the 4.1 or earlier kernels (which I think kept things sub-ms - Dmitry, please correct me). So I wanted to dampen my enthusiasm a touch for this, as there may yet further improvements needed. I'll try to get some more info on this as soon as I have details. thanks -john ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 21:42 ` Paul E. McKenney 2016-07-13 21:46 ` John Stultz @ 2016-07-13 22:25 ` John Stultz 1 sibling, 0 replies; 67+ messages in thread From: John Stultz @ 2016-07-13 22:25 UTC (permalink / raw) To: Paul McKenney Cc: Tejun Heo, Peter Zijlstra, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 2:42 PM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > On Wed, Jul 13, 2016 at 02:18:41PM -0700, Paul E. McKenney wrote: >> On Wed, Jul 13, 2016 at 05:05:26PM -0400, Tejun Heo wrote: >> > On Wed, Jul 13, 2016 at 02:03:15PM -0700, Paul E. McKenney wrote: >> > > Take the patch that I just sent out and make the choice of normal >> > > vs. expedited depend on CONFIG_PREEMPT_RT or whatever the -rt guys are >> > > calling it these days. Is there a low-latency Kconfig option other >> > > than CONFIG_NO_HZ_FULL? >> > >> > Sounds like a plan to me. >> >> I like the way we like each other's idea. Mutually assured laziness? ;-) > > But here is what mine might look like. Untested, probably does > not even build. Note that the default is -no- expediting, use the > rcusync.expedited kernel parameter to enable it. > > Thanx, Paul > > ------------------------------------------------------------------------ > > diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt > index 82b42c958d1c..b8bc9854e548 100644 > --- a/Documentation/kernel-parameters.txt > +++ b/Documentation/kernel-parameters.txt > @@ -3229,6 +3229,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. > energy efficiency by requiring that the kthreads > periodically wake up to do the polling. > > + rcusync.expedited [KNL] > + Specify that the rcusync mechanism use expedited > + grace periods. As of mid-2016, this affects > + per-CPU rwsems. > + > rcutree.blimit= [KNL] > Set maximum number of finished RCU callbacks to > process in one batch. > diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c > index be922c9f3d37..5bc5bef2e00a 100644 > --- a/kernel/rcu/sync.c > +++ b/kernel/rcu/sync.c > @@ -22,6 +22,14 @@ > > #include <linux/rcu_sync.h> > #include <linux/sched.h> > +#include <linux/moduleparam.h> > +#include <linux/module.h> > + > +MODULE_ALIAS("rcusync"); > +#ifdef MODULE_PARAM_PREFIX > +#undef MODULE_PARAM_PREFIX > +#endif > +#define MODULE_PARAM_PREFIX "rcusync." > > #ifdef CONFIG_PROVE_RCU > #define __INIT_HELD(func) .held = func, > @@ -29,7 +37,7 @@ > #define __INIT_HELD(func) > #endif > > -static const struct { > +static struct { > void (*sync)(void); > void (*call)(struct rcu_head *, void (*)(struct rcu_head *)); > void (*wait)(void); > @@ -62,6 +70,20 @@ enum { CB_IDLE = 0, CB_PENDING, CB_REPLAY }; > > #define rss_lock gp_wait.lock > > +static bool expedited; > +module_param(expedited, bool, 0444); > + > +static int __init rcu_sync_early_init(void) > +{ > + if (expedited) { > + gp_ops[RCU_SYNC].sync = synchronize_rcu_expedited; > + gp_ops[RCU_SCHED_SYNC].sync = synchronize_sched_expedited; > + gp_ops[RCU_BH_SYNC].sync = synchronize_rcu_bh_expedited; > + } So one minor nit here, with the config based default, you might want to put some sort of informative message specifying that expidited was used. This would help narrow down if it was or wasn't enabled when folks see problems, since it wouldn't be otherwise obvious from a dmesg log. thanks -john ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 21:18 ` Paul E. McKenney 2016-07-13 21:42 ` Paul E. McKenney @ 2016-07-13 22:01 ` Tejun Heo 2016-07-13 22:33 ` Paul E. McKenney 2016-07-14 6:49 ` Peter Zijlstra 1 sibling, 2 replies; 67+ messages in thread From: Tejun Heo @ 2016-07-13 22:01 UTC (permalink / raw) To: Paul E. McKenney Cc: Peter Zijlstra, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov Hello, Paul. On Wed, Jul 13, 2016 at 02:18:41PM -0700, Paul E. McKenney wrote: > On Wed, Jul 13, 2016 at 05:05:26PM -0400, Tejun Heo wrote: > > On Wed, Jul 13, 2016 at 02:03:15PM -0700, Paul E. McKenney wrote: > > > Take the patch that I just sent out and make the choice of normal > > > vs. expedited depend on CONFIG_PREEMPT_RT or whatever the -rt guys are > > > calling it these days. Is there a low-latency Kconfig option other > > > than CONFIG_NO_HZ_FULL? > > > > Sounds like a plan to me. > > I like the way we like each other's idea. Mutually assured laziness? ;-) Heh, indeed. :) Technically, I think the lglock approach would be better here given the combination of requirements; however, it's quite a bit more code which would likely require some sophistications down the line (like blocking new readers first at the start of down_write). If we have to go there, we'll go there but for now I think it'd be simpler to conditionally switch to the expedited operations. It can be a config option which is selected by !RT as you suggested. If anyone hits an actual issue with that, we can go for the lglock thing. Thanks. -- tejun ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 22:01 ` Tejun Heo @ 2016-07-13 22:33 ` Paul E. McKenney 2016-07-14 6:49 ` Peter Zijlstra 1 sibling, 0 replies; 67+ messages in thread From: Paul E. McKenney @ 2016-07-13 22:33 UTC (permalink / raw) To: Tejun Heo Cc: Peter Zijlstra, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 06:01:28PM -0400, Tejun Heo wrote: > Hello, Paul. > > On Wed, Jul 13, 2016 at 02:18:41PM -0700, Paul E. McKenney wrote: > > On Wed, Jul 13, 2016 at 05:05:26PM -0400, Tejun Heo wrote: > > > On Wed, Jul 13, 2016 at 02:03:15PM -0700, Paul E. McKenney wrote: > > > > Take the patch that I just sent out and make the choice of normal > > > > vs. expedited depend on CONFIG_PREEMPT_RT or whatever the -rt guys are > > > > calling it these days. Is there a low-latency Kconfig option other > > > > than CONFIG_NO_HZ_FULL? > > > > > > Sounds like a plan to me. > > > > I like the way we like each other's idea. Mutually assured laziness? ;-) > > Heh, indeed. :) > > Technically, I think the lglock approach would be better here given > the combination of requirements; however, it's quite a bit more code > which would likely require some sophistications down the line (like > blocking new readers first at the start of down_write). If we have to > go there, we'll go there but for now I think it'd be simpler to > conditionally switch to the expedited operations. It can be a config > option which is selected by !RT as you suggested. If anyone hits an > actual issue with that, we can go for the lglock thing. Fair enough! ;-) Thanx, Paul ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 22:01 ` Tejun Heo 2016-07-13 22:33 ` Paul E. McKenney @ 2016-07-14 6:49 ` Peter Zijlstra 2016-07-14 11:20 ` Tejun Heo 1 sibling, 1 reply; 67+ messages in thread From: Peter Zijlstra @ 2016-07-14 6:49 UTC (permalink / raw) To: Tejun Heo Cc: Paul E. McKenney, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 06:01:28PM -0400, Tejun Heo wrote: > Technically, I think the lglock approach would be better here given > the combination of requirements; however, it's quite a bit more code > which would likely require some sophistications down the line (like > blocking new readers first at the start of down_write). So the immediate problem with lg style locks is that the 'local' lock will not stay local since these are preemptible locks we can get migrations etc.. All fixable, but still. > If we have to > go there, we'll go there but for now I think it'd be simpler to > conditionally switch to the expedited operations. It can be a config > option which is selected by !RT as you suggested. If anyone hits an > actual issue with that, we can go for the lglock thing. So the main objection I have is that this isn't a fundamental fix, this only cures things because Android only runs on small machines. If someone with a big computer tries to do the same things we're up some creek without no paddle. There's just no way we can make a global writer 'fast'. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 6:49 ` Peter Zijlstra @ 2016-07-14 11:20 ` Tejun Heo 2016-07-14 12:11 ` Peter Zijlstra 0 siblings, 1 reply; 67+ messages in thread From: Tejun Heo @ 2016-07-14 11:20 UTC (permalink / raw) To: Peter Zijlstra Cc: Paul E. McKenney, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Thu, Jul 14, 2016 at 08:49:56AM +0200, Peter Zijlstra wrote: > On Wed, Jul 13, 2016 at 06:01:28PM -0400, Tejun Heo wrote: > > > Technically, I think the lglock approach would be better here given > > the combination of requirements; however, it's quite a bit more code > > which would likely require some sophistications down the line (like > > blocking new readers first at the start of down_write). > > So the immediate problem with lg style locks is that the 'local' lock > will not stay local since these are preemptible locks we can get > migrations etc.. > > All fixable, but still. In this case, the locks are read-locked only across operations which change process hierarchy. They'll occasionally get migrated while holding the lock for sure but not often enough to matter. > > If we have to > > go there, we'll go there but for now I think it'd be simpler to > > conditionally switch to the expedited operations. It can be a config > > option which is selected by !RT as you suggested. If anyone hits an > > actual issue with that, we can go for the lglock thing. > > So the main objection I have is that this isn't a fundamental fix, this > only cures things because Android only runs on small machines. > > If someone with a big computer tries to do the same things we're up some > creek without no paddle. There's just no way we can make a global writer > 'fast'. How so? As the number of cores increases, it'll get proportionally more expensive as the same operation is performed on more CPUs; however, the latency is dependent on the slowest one and it'll get higher more often with more number of CPUs but not drastically. Latency won't go up proportionally with the number of CPUs. For the most part, we're paying more in terms of processing overhead, not latency. Thanks. -- tejun ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 11:20 ` Tejun Heo @ 2016-07-14 12:11 ` Peter Zijlstra 2016-07-14 15:14 ` Tejun Heo 0 siblings, 1 reply; 67+ messages in thread From: Peter Zijlstra @ 2016-07-14 12:11 UTC (permalink / raw) To: Tejun Heo Cc: Paul E. McKenney, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Thu, Jul 14, 2016 at 07:20:46AM -0400, Tejun Heo wrote: > On Thu, Jul 14, 2016 at 08:49:56AM +0200, Peter Zijlstra wrote: > > So the immediate problem with lg style locks is that the 'local' lock > > will not stay local since these are preemptible locks we can get > > migrations etc.. > > > > All fixable, but still. > > In this case, the locks are read-locked only across operations which > change process hierarchy. They'll occasionally get migrated while > holding the lock for sure but not often enough to matter. Means having to change the interface to pass along what 'local' is, like srcu_read_lock(). > > So the main objection I have is that this isn't a fundamental fix, this > > only cures things because Android only runs on small machines. > > > > If someone with a big computer tries to do the same things we're up some > > creek without no paddle. There's just no way we can make a global writer > > 'fast'. > > How so? As the number of cores increases, it'll get proportionally > more expensive as the same operation is performed on more CPUs; > however, the latency is dependent on the slowest one and it'll get > higher more often with more number of CPUs but not drastically. A global lock on 4 or 8 socket machines with all 200+ cpus trying to use it really stinks. Remember, they switch cgroups at really rather high rates here, because of that binder stuff. I don't see how you can defend a global lock here :/ Global locks only work when writers are extremely rare, and clearly that premise is false. Also note that since these are preemptible locks, you can get unbounded priority inversions. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 12:11 ` Peter Zijlstra @ 2016-07-14 15:14 ` Tejun Heo 0 siblings, 0 replies; 67+ messages in thread From: Tejun Heo @ 2016-07-14 15:14 UTC (permalink / raw) To: Peter Zijlstra Cc: Paul E. McKenney, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Thu, Jul 14, 2016 at 02:11:01PM +0200, Peter Zijlstra wrote: > > How so? As the number of cores increases, it'll get proportionally > > more expensive as the same operation is performed on more CPUs; > > however, the latency is dependent on the slowest one and it'll get > > higher more often with more number of CPUs but not drastically. > > A global lock on 4 or 8 socket machines with all 200+ cpus trying to > use it really stinks. That's why we're using percpu lock here. With the right implementation the write locking latency shouldn't be proportional to the number of cores. The total processing overhead could be. > Remember, they switch cgroups at really rather high rates here, because > of that binder stuff. I don't see how you can defend a global lock here > :/ Global locks only work when writers are extremely rare, and clearly > that premise is false. This is one of the most eccentric uses and if I'm not mistaken they were even doing memcg charge immigration on fore <-> background switches which involve re-labeling each page. And even with binder, migration isn't nearly hot enough to matter for the most part even when it's emitting IPIs globally. We can split the locking but it just isn't necessary at this point. More downsides than upsides. If we actually need that, let's go there. Thanks. -- tejun ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 20:51 ` Peter Zijlstra 2016-07-13 21:01 ` Tejun Heo 2016-07-13 21:03 ` Paul E. McKenney @ 2016-07-14 13:18 ` Peter Zijlstra 2016-07-14 14:14 ` Peter Zijlstra ` (4 more replies) 2 siblings, 5 replies; 67+ messages in thread From: Peter Zijlstra @ 2016-07-14 13:18 UTC (permalink / raw) To: Tejun Heo Cc: John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov, Paul E. McKenney On Wed, Jul 13, 2016 at 10:51:02PM +0200, Peter Zijlstra wrote: > So, IIRC, the trade-off is a full memory barrier in read_lock and > read_unlock() vs sync_sched() in write. > > Full memory barriers are expensive and while the combined cost might > well exceed the cost of the sync_sched() it doesn't suffer the latency > issues. > > Not sure if we can frob the two in a single codebase, but I can have a > poke if Oleg or Paul doesn't beat me to it. OK, not too horrible if I say so myself :-) The below is a compile tested only first draft so far. I'll go give it some runtime next. --- fs/super.c | 3 +- include/linux/percpu-rwsem.h | 96 +++++++++++++++-- include/linux/rcu_sync.h | 2 +- kernel/locking/percpu-rwsem.c | 243 +++++++++++++++++++++++++----------------- kernel/rcu/sync.c | 15 +++ 5 files changed, 249 insertions(+), 110 deletions(-) diff --git a/fs/super.c b/fs/super.c index d78b9847e6cb..8ff18af7703f 100644 --- a/fs/super.c +++ b/fs/super.c @@ -195,7 +195,8 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags) for (i = 0; i < SB_FREEZE_LEVELS; i++) { if (__percpu_init_rwsem(&s->s_writers.rw_sem[i], sb_writers_name[i], - &type->s_writers_key[i])) + &type->s_writers_key[i], + PERCPU_RWSEM_READER)) goto fail; } init_waitqueue_head(&s->s_writers.wait_unfrozen); diff --git a/include/linux/percpu-rwsem.h b/include/linux/percpu-rwsem.h index c2fa3ecb0dce..5e1c2b029e3a 100644 --- a/include/linux/percpu-rwsem.h +++ b/include/linux/percpu-rwsem.h @@ -10,29 +10,107 @@ struct percpu_rw_semaphore { struct rcu_sync rss; - unsigned int __percpu *fast_read_ctr; + unsigned int __percpu *refcount; struct rw_semaphore rw_sem; - atomic_t slow_read_ctr; - wait_queue_head_t write_waitq; + wait_queue_head_t writer; + int state; }; -extern void percpu_down_read(struct percpu_rw_semaphore *); -extern int percpu_down_read_trylock(struct percpu_rw_semaphore *); -extern void percpu_up_read(struct percpu_rw_semaphore *); +extern void __percpu_down_read(struct percpu_rw_semaphore *); +extern int __percpu_down_read_trylock(struct percpu_rw_semaphore *); +extern void __percpu_up_read(struct percpu_rw_semaphore *); + +static inline void percpu_down_read(struct percpu_rw_semaphore *sem) +{ + might_sleep(); + + rwsem_acquire_read(&sem->rw_sem.dep_map, 0, 0, _RET_IP_); + + preempt_disable(); + /* + * We are in an RCU-sched read-side critical section, so the writer + * cannot both change sem->state from readers_fast and start checking + * counters while we are here. So if we see !sem->state, we know that + * the writer won't be checking until we're past the preempt_enable() + * and that one the synchronize_sched() is done, the writer will see + * anything we did within this RCU-sched read-size critical section. + */ + __this_cpu_inc(*sem->refcount); + if (unlikely(!rcu_sync_is_idle(&sem->rss))) + __percpu_down_read(sem); /* Unconditional memory barrier */ + preempt_enable(); + /* + * The barrier() from preempt_enable() prevents the compiler from + * bleeding the critical section out. + */ +} + +static inline int percpu_down_read_trylock(struct percpu_rw_semaphore *sem) +{ + int ret = 1; + + preempt_disable(); + /* + * Same as in percpu_down_read(). + */ + __this_cpu_inc(*sem->refcount); + if (unlikely(!rcu_sync_is_idle(&sem->rss))) + ret = __percpu_down_read_trylock(sem); + preempt_enable(); + /* + * The barrier() from preempt_enable() prevents the compiler from + * bleeding the critical section out. + */ + + if (ret) + rwsem_acquire_read(&sem->rw_sem.dep_map, 0, 1, _RET_IP_); + + return ret; +} + +static inline void percpu_up_read(struct percpu_rw_semaphore *sem) +{ + /* + * The barrier() in preempt_disable() prevents the compiler from + * bleeding the critical section out. + */ + preempt_disable(); + /* + * Same as in percpu_down_read(). + */ + if (likely(rcu_sync_is_idle(&sem->rss))) + __this_cpu_dec(*sem->refcount); + else + __percpu_up_read(sem); /* Unconditional memory barrier */ + preempt_enable(); + + rwsem_release(&sem->rw_sem.dep_map, 1, _RET_IP_); +} extern void percpu_down_write(struct percpu_rw_semaphore *); extern void percpu_up_write(struct percpu_rw_semaphore *); +enum percpu_rwsem_bias { PERCPU_RWSEM_READER, PERCPU_RWSEM_WRITER }; + extern int __percpu_init_rwsem(struct percpu_rw_semaphore *, - const char *, struct lock_class_key *); + const char *, struct lock_class_key *, + enum percpu_rwsem_bias bias); + extern void percpu_free_rwsem(struct percpu_rw_semaphore *); -#define percpu_init_rwsem(brw) \ +#define percpu_init_rwsem(sem) \ ({ \ static struct lock_class_key rwsem_key; \ - __percpu_init_rwsem(brw, #brw, &rwsem_key); \ + __percpu_init_rwsem(sem, #sem, &rwsem_key, \ + PERCPU_RWSEM_READER); \ }) +#define percpu_init_rwsem_writer(sem) \ +({ \ + static struct lock_class_key rwsem_key; \ + __percpu_init_rwsem(sem, #sem, &rwsem_key,i \ + PERCPU_RWSEM_WRITER); \ +}) #define percpu_rwsem_is_held(sem) lockdep_is_held(&(sem)->rw_sem) diff --git a/include/linux/rcu_sync.h b/include/linux/rcu_sync.h index a63a33e6196e..e556baaf785e 100644 --- a/include/linux/rcu_sync.h +++ b/include/linux/rcu_sync.h @@ -26,7 +26,7 @@ #include <linux/wait.h> #include <linux/rcupdate.h> -enum rcu_sync_type { RCU_SYNC, RCU_SCHED_SYNC, RCU_BH_SYNC }; +enum rcu_sync_type { RCU_SYNC, RCU_SCHED_SYNC, RCU_BH_SYNC, RCU_NONE }; /* Structure to mediate between updaters and fastpath-using readers. */ struct rcu_sync { diff --git a/kernel/locking/percpu-rwsem.c b/kernel/locking/percpu-rwsem.c index bec0b647f9cc..be37c7732b54 100644 --- a/kernel/locking/percpu-rwsem.c +++ b/kernel/locking/percpu-rwsem.c @@ -8,152 +8,197 @@ #include <linux/sched.h> #include <linux/errno.h> -int __percpu_init_rwsem(struct percpu_rw_semaphore *brw, - const char *name, struct lock_class_key *rwsem_key) +enum { readers_slow, readers_block }; + +int __percpu_init_rwsem(struct percpu_rw_semaphore *sem, + const char *name, struct lock_class_key *rwsem_key, + enum percpu_rwsem_bias bias) { - brw->fast_read_ctr = alloc_percpu(int); - if (unlikely(!brw->fast_read_ctr)) + sem->refcount = alloc_percpu(int); + if (unlikely(!sem->refcount)) return -ENOMEM; /* ->rw_sem represents the whole percpu_rw_semaphore for lockdep */ - __init_rwsem(&brw->rw_sem, name, rwsem_key); - rcu_sync_init(&brw->rss, RCU_SCHED_SYNC); - atomic_set(&brw->slow_read_ctr, 0); - init_waitqueue_head(&brw->write_waitq); + rcu_sync_init(&sem->rss, bias == PERCPU_RWSEM_READER ? + RCU_SCHED_SYNC : + RCU_NONE); + __init_rwsem(&sem->rw_sem, name, rwsem_key); + init_waitqueue_head(&sem->writer); + sem->state = readers_slow; return 0; } EXPORT_SYMBOL_GPL(__percpu_init_rwsem); -void percpu_free_rwsem(struct percpu_rw_semaphore *brw) +void percpu_free_rwsem(struct percpu_rw_semaphore *sem) { /* * XXX: temporary kludge. The error path in alloc_super() * assumes that percpu_free_rwsem() is safe after kzalloc(). */ - if (!brw->fast_read_ctr) + if (!sem->refcount) return; - rcu_sync_dtor(&brw->rss); - free_percpu(brw->fast_read_ctr); - brw->fast_read_ctr = NULL; /* catch use after free bugs */ + rcu_sync_dtor(&sem->rss); + free_percpu(sem->refcount); + sem->refcount = NULL; /* catch use after free bugs */ } EXPORT_SYMBOL_GPL(percpu_free_rwsem); -/* - * This is the fast-path for down_read/up_read. If it succeeds we rely - * on the barriers provided by rcu_sync_enter/exit; see the comments in - * percpu_down_write() and percpu_up_write(). - * - * If this helper fails the callers rely on the normal rw_semaphore and - * atomic_dec_and_test(), so in this case we have the necessary barriers. - */ -static bool update_fast_ctr(struct percpu_rw_semaphore *brw, unsigned int val) +void __percpu_down_read(struct percpu_rw_semaphore *sem) { - bool success; + /* + * Due to having preemption disabled the decrement happens on + * the same CPU as the increment, avoiding the + * increment-on-one-CPU-and-decrement-on-another problem. + * + * And yes, if the reader misses the writer's assignment of + * readers_block to sem->state, then the writer is + * guaranteed to see the reader's increment. Conversely, any + * readers that increment their sem->refcount after the + * writer looks are guaranteed to see the readers_block value, + * which in turn means that they are guaranteed to immediately + * decrement their sem->refcount, so that it doesn't matter + * that the writer missed them. + */ - preempt_disable(); - success = rcu_sync_is_idle(&brw->rss); - if (likely(success)) - __this_cpu_add(*brw->fast_read_ctr, val); - preempt_enable(); + smp_mb(); /* A matches D */ - return success; -} + /* + * If !readers_block the critical section starts here, matched by the + * release in percpu_up_write(). + */ + if (likely(smp_load_acquire(&sem->state) != readers_block)) + return; -/* - * Like the normal down_read() this is not recursive, the writer can - * come after the first percpu_down_read() and create the deadlock. - * - * Note: returns with lock_is_held(brw->rw_sem) == T for lockdep, - * percpu_up_read() does rwsem_release(). This pairs with the usage - * of ->rw_sem in percpu_down/up_write(). - */ -void percpu_down_read(struct percpu_rw_semaphore *brw) -{ - might_sleep(); - rwsem_acquire_read(&brw->rw_sem.dep_map, 0, 0, _RET_IP_); + /* + * Per the above comment; we still have preemption disabled and + * will thus decrement on the same CPU as we incremented. + */ + __percpu_up_read(sem); - if (likely(update_fast_ctr(brw, +1))) - return; + /* + * We either call schedule() in the wait, or we'll fall through + * and reschedule on the preempt_enable() in percpu_down_read(). + */ + preempt_enable_no_resched(); + + /* + * Avoid lockdep for the down/up_read() we already have them. + */ + __down_read(&sem->rw_sem); + __this_cpu_inc(*sem->refcount); + __up_read(&sem->rw_sem); - /* Avoid rwsem_acquire_read() and rwsem_release() */ - __down_read(&brw->rw_sem); - atomic_inc(&brw->slow_read_ctr); - __up_read(&brw->rw_sem); + preempt_disable(); } -EXPORT_SYMBOL_GPL(percpu_down_read); +EXPORT_SYMBOL_GPL(__percpu_down_read); -int percpu_down_read_trylock(struct percpu_rw_semaphore *brw) +int __percpu_down_read_trylock(struct percpu_rw_semaphore *sem) { - if (unlikely(!update_fast_ctr(brw, +1))) { - if (!__down_read_trylock(&brw->rw_sem)) - return 0; - atomic_inc(&brw->slow_read_ctr); - __up_read(&brw->rw_sem); - } - - rwsem_acquire_read(&brw->rw_sem.dep_map, 0, 1, _RET_IP_); - return 1; + smp_mb(); /* A matches D */ + + if (likely(smp_load_acquire(&sem->state) != readers_block)) + return 1; + + __percpu_up_read(sem); + return 0; } +EXPORT_SYMBOL_GPL(__percpu_down_read_trylock); -void percpu_up_read(struct percpu_rw_semaphore *brw) +void __percpu_up_read(struct percpu_rw_semaphore *sem) { - rwsem_release(&brw->rw_sem.dep_map, 1, _RET_IP_); - - if (likely(update_fast_ctr(brw, -1))) - return; + smp_mb(); /* B matches C */ + /* + * In other words, if they see our decrement (presumably to aggregate + * zero, as that is the only time it matters) they will also see our + * critical section. + */ + __this_cpu_dec(*sem->refcount); - /* false-positive is possible but harmless */ - if (atomic_dec_and_test(&brw->slow_read_ctr)) - wake_up_all(&brw->write_waitq); + /* Prod writer to recheck readers_active */ + wake_up(&sem->writer); } -EXPORT_SYMBOL_GPL(percpu_up_read); +EXPORT_SYMBOL_GPL(__percpu_up_read); + +#define per_cpu_sum(var) \ +({ \ + typeof(var) __sum = 0; \ + int cpu; \ + compiletime_assert_atomic_type(__sum); \ + for_each_possible_cpu(cpu) \ + __sum += per_cpu(var, cpu); \ + __sum; \ +}) -static int clear_fast_ctr(struct percpu_rw_semaphore *brw) +/* + * Return true if the modular sum of the sem->refcount per-CPU variable is + * zero. If this sum is zero, then it is stable due to the fact that if any + * newly arriving readers increment a given counter, they will immediately + * decrement that same counter. + */ +static bool readers_active_check(struct percpu_rw_semaphore *sem) { - unsigned int sum = 0; - int cpu; + if (per_cpu_sum(*sem->refcount) != 0) + return false; + + /* + * If we observed the decrement; ensure we see the entire critical + * section. + */ - for_each_possible_cpu(cpu) { - sum += per_cpu(*brw->fast_read_ctr, cpu); - per_cpu(*brw->fast_read_ctr, cpu) = 0; - } + smp_mb(); /* C matches B */ - return sum; + return true; } -void percpu_down_write(struct percpu_rw_semaphore *brw) +void percpu_down_write(struct percpu_rw_semaphore *sem) { + down_write(&sem->rw_sem); + + /* Notify readers to take the slow path. */ + rcu_sync_enter(&sem->rss); + /* - * Make rcu_sync_is_idle() == F and thus disable the fast-path in - * percpu_down_read() and percpu_up_read(), and wait for gp pass. - * - * The latter synchronises us with the preceding readers which used - * the fast-past, so we can not miss the result of __this_cpu_add() - * or anything else inside their criticial sections. + * Notify new readers to block; up until now, and thus throughout the + * longish rcu_sync_enter() above, new readers could still come in. */ - rcu_sync_enter(&brw->rss); + sem->state = readers_block; - /* exclude other writers, and block the new readers completely */ - down_write(&brw->rw_sem); + smp_mb(); /* D matches A */ - /* nobody can use fast_read_ctr, move its sum into slow_read_ctr */ - atomic_add(clear_fast_ctr(brw), &brw->slow_read_ctr); + /* + * If they don't see our writer of readers_block to sem->state, + * then we are guaranteed to see their sem->refcount increment, and + * therefore will wait for them. + */ - /* wait for all readers to complete their percpu_up_read() */ - wait_event(brw->write_waitq, !atomic_read(&brw->slow_read_ctr)); + /* Wait for all now active readers to complete. */ + wait_event(sem->writer, readers_active_check(sem)); } -EXPORT_SYMBOL_GPL(percpu_down_write); -void percpu_up_write(struct percpu_rw_semaphore *brw) +void percpu_up_write(struct percpu_rw_semaphore *sem) { - /* release the lock, but the readers can't use the fast-path */ - up_write(&brw->rw_sem); /* - * Enable the fast-path in percpu_down_read() and percpu_up_read() - * but only after another gp pass; this adds the necessary barrier - * to ensure the reader can't miss the changes done by us. + * Signal the writer is done, no fast path yet. + * + * One reason that we cannot just immediately flip to readers_fast is + * that new readers might fail to see the results of this writer's + * critical section. + * + * Therefore we force it through the slow path which guarantees an + * acquire and thereby guarantees the critical section's consistency. + */ + smp_store_release(&sem->state, readers_slow); + + /* + * Release the write lock, this will allow readers back in the game. + */ + up_write(&sem->rw_sem); + + /* + * Once this completes (at least one RCU grace period hence) the reader + * fast path will be available again. Safe to use outside the exclusive + * write lock because its counting. */ - rcu_sync_exit(&brw->rss); + rcu_sync_exit(&sem->rss); } -EXPORT_SYMBOL_GPL(percpu_up_write); diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c index be922c9f3d37..48055bf629af 100644 --- a/kernel/rcu/sync.c +++ b/kernel/rcu/sync.c @@ -55,6 +55,7 @@ static const struct { .wait = rcu_barrier_bh, __INIT_HELD(rcu_read_lock_bh_held) }, + [RCU_NONE] = { }, }; enum { GP_IDLE = 0, GP_PENDING, GP_PASSED }; @@ -65,6 +66,9 @@ enum { CB_IDLE = 0, CB_PENDING, CB_REPLAY }; #ifdef CONFIG_PROVE_RCU void rcu_sync_lockdep_assert(struct rcu_sync *rsp) { + if (rsp->gp_type == RCU_NONE) + return; + RCU_LOCKDEP_WARN(!gp_ops[rsp->gp_type].held(), "suspicious rcu_sync_is_idle() usage"); } @@ -80,6 +84,8 @@ void rcu_sync_init(struct rcu_sync *rsp, enum rcu_sync_type type) memset(rsp, 0, sizeof(*rsp)); init_waitqueue_head(&rsp->gp_wait); rsp->gp_type = type; + if (rsp->gp_type == RCU_NONE) + rsp->gp_state = GP_PENDING; /* anything !0 */ } /** @@ -101,6 +107,9 @@ void rcu_sync_enter(struct rcu_sync *rsp) { bool need_wait, need_sync; + if (rsp->gp_type == RCU_NONE) + return; + spin_lock_irq(&rsp->rss_lock); need_wait = rsp->gp_count++; need_sync = rsp->gp_state == GP_IDLE; @@ -188,6 +197,9 @@ static void rcu_sync_func(struct rcu_head *rcu) */ void rcu_sync_exit(struct rcu_sync *rsp) { + if (rsp->gp_type == RCU_NONE) + return; + spin_lock_irq(&rsp->rss_lock); if (!--rsp->gp_count) { if (rsp->cb_state == CB_IDLE) { @@ -208,6 +220,9 @@ void rcu_sync_dtor(struct rcu_sync *rsp) { int cb_state; + if (rsp->gp_type == RCU_NONE) + return; + BUG_ON(rsp->gp_count); spin_lock_irq(&rsp->rss_lock); ^ permalink raw reply related [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 13:18 ` Peter Zijlstra @ 2016-07-14 14:14 ` Peter Zijlstra 2016-07-14 14:58 ` Oleg Nesterov ` (3 subsequent siblings) 4 siblings, 0 replies; 67+ messages in thread From: Peter Zijlstra @ 2016-07-14 14:14 UTC (permalink / raw) To: Tejun Heo Cc: John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov, Paul E. McKenney On Thu, Jul 14, 2016 at 03:18:09PM +0200, Peter Zijlstra wrote: > On Wed, Jul 13, 2016 at 10:51:02PM +0200, Peter Zijlstra wrote: > > So, IIRC, the trade-off is a full memory barrier in read_lock and > > read_unlock() vs sync_sched() in write. > > > > Full memory barriers are expensive and while the combined cost might > > well exceed the cost of the sync_sched() it doesn't suffer the latency > > issues. > > > > Not sure if we can frob the two in a single codebase, but I can have a > > poke if Oleg or Paul doesn't beat me to it. > > OK, not too horrible if I say so myself :-) > > The below is a compile tested only first draft so far. I'll go give it > some runtime next. Doesn't explode if I run: root@ivb-ep:/cgroup# mkdir ponies; for ((i=0; i<60; i++)) ; do while :; do echo $$ > tasks; echo $$ > ponies/tasks ; done & done with cgroup using either READER or WRITER bias. So passes light torture. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 13:18 ` Peter Zijlstra 2016-07-14 14:14 ` Peter Zijlstra @ 2016-07-14 14:58 ` Oleg Nesterov 2016-07-14 16:14 ` Peter Zijlstra 2016-07-14 16:37 ` Peter Zijlstra 2016-07-14 16:23 ` Paul E. McKenney ` (2 subsequent siblings) 4 siblings, 2 replies; 67+ messages in thread From: Oleg Nesterov @ 2016-07-14 14:58 UTC (permalink / raw) To: Peter Zijlstra Cc: Tejun Heo, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Paul E. McKenney On 07/14, Peter Zijlstra wrote: > > OK, not too horrible if I say so myself :-) > > The below is a compile tested only first draft so far. I'll go give it > some runtime next. Yes, thanks. But note that we do not need RCU_NONE. All we need is the trivial change below. Damn, I am trying to find my old rcu-sync patches which I didn't send, but can't... OK, this almost off-topic right now, just this "enter" is ugly and we can't switch the slow/fast modes dynamically. The rest of you patch is "optimize the slow path" and we already discussed it before, I personally like it. Perhaps you can redo it without RCU_NONE part? Of course, this leads to another question: do we really need rcu-sync at all, or should we change percpu-rwsem to always work in the "slow" mode which is not that slow with your change... I'd like to keep it ;) What do you think? Oleg. --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -5605,6 +5605,8 @@ int __init cgroup_init(void) BUG_ON(cgroup_init_cftypes(NULL, cgroup_dfl_base_files)); BUG_ON(cgroup_init_cftypes(NULL, cgroup_legacy_base_files)); + rcu_sync_enter(&cgroup_threadgroup_rwsem.rss); + get_user_ns(init_cgroup_ns.user_ns); mutex_lock(&cgroup_mutex); ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 14:58 ` Oleg Nesterov @ 2016-07-14 16:14 ` Peter Zijlstra 2016-07-14 16:37 ` Peter Zijlstra 1 sibling, 0 replies; 67+ messages in thread From: Peter Zijlstra @ 2016-07-14 16:14 UTC (permalink / raw) To: Oleg Nesterov Cc: Tejun Heo, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Paul E. McKenney On Thu, Jul 14, 2016 at 04:58:44PM +0200, Oleg Nesterov wrote: > > Of course, this leads to another question: do we really need rcu-sync at > all, or should we change percpu-rwsem to always work in the "slow" mode > which is not that slow with your change... I'd like to keep it ;) > > What do you think? Yes, I think we wants to keep it. There are users where the read size cost really are performance critical. I still have to repost that lglock removal series for example, which replaces the fs/locks lglock with a percpu-rwsem. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 14:58 ` Oleg Nesterov 2016-07-14 16:14 ` Peter Zijlstra @ 2016-07-14 16:37 ` Peter Zijlstra 2016-07-14 17:05 ` Oleg Nesterov 1 sibling, 1 reply; 67+ messages in thread From: Peter Zijlstra @ 2016-07-14 16:37 UTC (permalink / raw) To: Oleg Nesterov Cc: Tejun Heo, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Paul E. McKenney On Thu, Jul 14, 2016 at 04:58:44PM +0200, Oleg Nesterov wrote: > > But note that we do not need RCU_NONE. All we need is the trivial change > below. Hurm, maybe. So having that unbalanced keeps us in GP_PASSED state and since we'll never drop gp_count back to 0 nothing will ever happen. Cute, yes. > Damn, I am trying to find my old rcu-sync patches which I didn't > send, but can't... OK, this almost off-topic right now, just this "enter" > is ugly and we can't switch the slow/fast modes dynamically. > > The rest of you patch is "optimize the slow path" and we already discussed > it before, I personally like it. Perhaps you can redo it without RCU_NONE > part? Indeed, I rebased that patch on top of the current tree and had to add support for down_trylock() but otherwise much the same thing. I can send it out again. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 16:37 ` Peter Zijlstra @ 2016-07-14 17:05 ` Oleg Nesterov 0 siblings, 0 replies; 67+ messages in thread From: Oleg Nesterov @ 2016-07-14 17:05 UTC (permalink / raw) To: Peter Zijlstra Cc: Tejun Heo, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Paul E. McKenney On 07/14, Peter Zijlstra wrote: > > On Thu, Jul 14, 2016 at 04:58:44PM +0200, Oleg Nesterov wrote: > > > > But note that we do not need RCU_NONE. All we need is the trivial change > > below. > > Hurm, maybe. So having that unbalanced keeps us in GP_PASSED state and > since we'll never drop gp_count back to 0 nothing will ever happen. Yes, exactly. Of course, this is a bit ugly, I'll try to send some rcu-sync cleanups/simplifications later. Perhaps we can even add a "cgroup migration is not that cold as it was supposed" boot option for this rcu_sync_enter() for now, not sure. > > Damn, I am trying to find my old rcu-sync patches which I didn't > > send, but can't... OK, this almost off-topic right now, just this "enter" > > is ugly and we can't switch the slow/fast modes dynamically. > > > > The rest of you patch is "optimize the slow path" and we already discussed > > it before, I personally like it. Perhaps you can redo it without RCU_NONE > > part? > > Indeed, I rebased that patch on top of the current tree and had to add > support for down_trylock() but otherwise much the same thing. > > I can send it out again. Great, thanks! This should fix the problem. Oleg. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 13:18 ` Peter Zijlstra 2016-07-14 14:14 ` Peter Zijlstra 2016-07-14 14:58 ` Oleg Nesterov @ 2016-07-14 16:23 ` Paul E. McKenney 2016-07-14 16:45 ` Peter Zijlstra 2016-07-14 16:43 ` John Stultz 2016-07-14 18:09 ` Oleg Nesterov 4 siblings, 1 reply; 67+ messages in thread From: Paul E. McKenney @ 2016-07-14 16:23 UTC (permalink / raw) To: Peter Zijlstra Cc: Tejun Heo, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Thu, Jul 14, 2016 at 03:18:09PM +0200, Peter Zijlstra wrote: > On Wed, Jul 13, 2016 at 10:51:02PM +0200, Peter Zijlstra wrote: > > So, IIRC, the trade-off is a full memory barrier in read_lock and > > read_unlock() vs sync_sched() in write. > > > > Full memory barriers are expensive and while the combined cost might > > well exceed the cost of the sync_sched() it doesn't suffer the latency > > issues. > > > > Not sure if we can frob the two in a single codebase, but I can have a > > poke if Oleg or Paul doesn't beat me to it. > > OK, not too horrible if I say so myself :-) > > The below is a compile tested only first draft so far. I'll go give it > some runtime next. Hmmm... How does this handle the following sequence of events for the case where we are not biased towards the reader? o The per-CPU rwsem is set up with RCU_NONE and readers_slow (as opposed to readers_block). The rcu_sync ->gp_state is GP_PENDING, which means that rcu_sync_is_idle() will always return true. o Task A on CPU 0 runs percpu_down_read() to completion, and remains within the critical section. CPU 0's ->refcount is therefore 1. o Task B on CPU 1 does percpu_down_write(), which write-acquires ->rw_sem, does rcu_sync_enter() (which is a no-op due to RCU_NONE), sets ->state to readers_block, and is just now going to wait for readers, which first invokes readers_active_check(), which starts summing the ->refcount for CPUs 0, 1, and 2, obtaining the value 1 so far. o Task C CPU 2 enters percpu_down_read(), disables preemption, increments CPU 2's ->refcount, sees rcu_sync_is_idle() return true (so skips __percpu_down_read()), enables preemption, and enters its critical section. o Task C migrates to CPU 3 and invokes percpu_up_read(), which disables preemption, sees rcu_sync_is_idle() return true, calls __this_cpu_dec() on CPU 3's ->refcount, and enables preemption. The value of CPU 3's ->refcount is thus (unsigned int)-1. o Task B on CPU 1 continues execution in readers_active_check(), with the full sum being zero. So it looks to me like we have Task A as a writer at the same time that Task A is a reader, which would not be so good. So what am I missing here? And a couple of checkpatch nits below. Yes, I had to apply the patch to figure out what it was doing. ;-) Thanx, Paul > --- > fs/super.c | 3 +- > include/linux/percpu-rwsem.h | 96 +++++++++++++++-- > include/linux/rcu_sync.h | 2 +- > kernel/locking/percpu-rwsem.c | 243 +++++++++++++++++++++++++----------------- > kernel/rcu/sync.c | 15 +++ > 5 files changed, 249 insertions(+), 110 deletions(-) > > diff --git a/fs/super.c b/fs/super.c > index d78b9847e6cb..8ff18af7703f 100644 > --- a/fs/super.c > +++ b/fs/super.c > @@ -195,7 +195,8 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags) > for (i = 0; i < SB_FREEZE_LEVELS; i++) { > if (__percpu_init_rwsem(&s->s_writers.rw_sem[i], > sb_writers_name[i], > - &type->s_writers_key[i])) > + &type->s_writers_key[i], > + PERCPU_RWSEM_READER)) > goto fail; > } > init_waitqueue_head(&s->s_writers.wait_unfrozen); > diff --git a/include/linux/percpu-rwsem.h b/include/linux/percpu-rwsem.h > index c2fa3ecb0dce..5e1c2b029e3a 100644 > --- a/include/linux/percpu-rwsem.h > +++ b/include/linux/percpu-rwsem.h > @@ -10,29 +10,107 @@ > > struct percpu_rw_semaphore { > struct rcu_sync rss; > - unsigned int __percpu *fast_read_ctr; > + unsigned int __percpu *refcount; > struct rw_semaphore rw_sem; > - atomic_t slow_read_ctr; > - wait_queue_head_t write_waitq; > + wait_queue_head_t writer; > + int state; > }; > > -extern void percpu_down_read(struct percpu_rw_semaphore *); > -extern int percpu_down_read_trylock(struct percpu_rw_semaphore *); > -extern void percpu_up_read(struct percpu_rw_semaphore *); > +extern void __percpu_down_read(struct percpu_rw_semaphore *); > +extern int __percpu_down_read_trylock(struct percpu_rw_semaphore *); > +extern void __percpu_up_read(struct percpu_rw_semaphore *); > + > +static inline void percpu_down_read(struct percpu_rw_semaphore *sem) > +{ > + might_sleep(); > + > + rwsem_acquire_read(&sem->rw_sem.dep_map, 0, 0, _RET_IP_); > + > + preempt_disable(); > + /* > + * We are in an RCU-sched read-side critical section, so the writer > + * cannot both change sem->state from readers_fast and start checking > + * counters while we are here. So if we see !sem->state, we know that > + * the writer won't be checking until we're past the preempt_enable() > + * and that one the synchronize_sched() is done, the writer will see > + * anything we did within this RCU-sched read-size critical section. > + */ > + __this_cpu_inc(*sem->refcount); > + if (unlikely(!rcu_sync_is_idle(&sem->rss))) > + __percpu_down_read(sem); /* Unconditional memory barrier */ > + preempt_enable(); > + /* > + * The barrier() from preempt_enable() prevents the compiler from > + * bleeding the critical section out. > + */ > +} > + > +static inline int percpu_down_read_trylock(struct percpu_rw_semaphore *sem) > +{ > + int ret = 1; > + > + preempt_disable(); > + /* > + * Same as in percpu_down_read(). > + */ > + __this_cpu_inc(*sem->refcount); > + if (unlikely(!rcu_sync_is_idle(&sem->rss))) > + ret = __percpu_down_read_trylock(sem); > + preempt_enable(); > + /* > + * The barrier() from preempt_enable() prevents the compiler from > + * bleeding the critical section out. > + */ > + > + if (ret) > + rwsem_acquire_read(&sem->rw_sem.dep_map, 0, 1, _RET_IP_); > + > + return ret; > +} > + > +static inline void percpu_up_read(struct percpu_rw_semaphore *sem) > +{ > + /* > + * The barrier() in preempt_disable() prevents the compiler from > + * bleeding the critical section out. > + */ > + preempt_disable(); > + /* > + * Same as in percpu_down_read(). > + */ > + if (likely(rcu_sync_is_idle(&sem->rss))) > + __this_cpu_dec(*sem->refcount); > + else > + __percpu_up_read(sem); /* Unconditional memory barrier */ > + preempt_enable(); > + > + rwsem_release(&sem->rw_sem.dep_map, 1, _RET_IP_); > +} > > extern void percpu_down_write(struct percpu_rw_semaphore *); > extern void percpu_up_write(struct percpu_rw_semaphore *); > > +enum percpu_rwsem_bias { PERCPU_RWSEM_READER, PERCPU_RWSEM_WRITER }; > + > extern int __percpu_init_rwsem(struct percpu_rw_semaphore *, > - const char *, struct lock_class_key *); > + const char *, struct lock_class_key *, > + enum percpu_rwsem_bias bias); > + > extern void percpu_free_rwsem(struct percpu_rw_semaphore *); > > -#define percpu_init_rwsem(brw) \ > +#define percpu_init_rwsem(sem) \ > ({ \ > static struct lock_class_key rwsem_key; \ > - __percpu_init_rwsem(brw, #brw, &rwsem_key); \ > + __percpu_init_rwsem(sem, #sem, &rwsem_key, \ > + PERCPU_RWSEM_READER); \ > }) > > +#define percpu_init_rwsem_writer(sem) \ > +({ \ > + static struct lock_class_key rwsem_key; \ > + __percpu_init_rwsem(sem, #sem, &rwsem_key,i \ > + PERCPU_RWSEM_WRITER); \ > +}) > > #define percpu_rwsem_is_held(sem) lockdep_is_held(&(sem)->rw_sem) > > diff --git a/include/linux/rcu_sync.h b/include/linux/rcu_sync.h > index a63a33e6196e..e556baaf785e 100644 > --- a/include/linux/rcu_sync.h > +++ b/include/linux/rcu_sync.h > @@ -26,7 +26,7 @@ > #include <linux/wait.h> > #include <linux/rcupdate.h> > > -enum rcu_sync_type { RCU_SYNC, RCU_SCHED_SYNC, RCU_BH_SYNC }; > +enum rcu_sync_type { RCU_SYNC, RCU_SCHED_SYNC, RCU_BH_SYNC, RCU_NONE }; > > /* Structure to mediate between updaters and fastpath-using readers. */ > struct rcu_sync { > diff --git a/kernel/locking/percpu-rwsem.c b/kernel/locking/percpu-rwsem.c > index bec0b647f9cc..be37c7732b54 100644 > --- a/kernel/locking/percpu-rwsem.c > +++ b/kernel/locking/percpu-rwsem.c > @@ -8,152 +8,197 @@ > #include <linux/sched.h> > #include <linux/errno.h> > > -int __percpu_init_rwsem(struct percpu_rw_semaphore *brw, > - const char *name, struct lock_class_key *rwsem_key) > +enum { readers_slow, readers_block }; > + > +int __percpu_init_rwsem(struct percpu_rw_semaphore *sem, > + const char *name, struct lock_class_key *rwsem_key, > + enum percpu_rwsem_bias bias) > { > - brw->fast_read_ctr = alloc_percpu(int); > - if (unlikely(!brw->fast_read_ctr)) > + sem->refcount = alloc_percpu(int); > + if (unlikely(!sem->refcount)) > return -ENOMEM; > > /* ->rw_sem represents the whole percpu_rw_semaphore for lockdep */ > - __init_rwsem(&brw->rw_sem, name, rwsem_key); > - rcu_sync_init(&brw->rss, RCU_SCHED_SYNC); > - atomic_set(&brw->slow_read_ctr, 0); > - init_waitqueue_head(&brw->write_waitq); > + rcu_sync_init(&sem->rss, bias == PERCPU_RWSEM_READER ? > + RCU_SCHED_SYNC : Whitespace complaint on prior two lines. > + RCU_NONE); > + __init_rwsem(&sem->rw_sem, name, rwsem_key); > + init_waitqueue_head(&sem->writer); > + sem->state = readers_slow; > return 0; > } > EXPORT_SYMBOL_GPL(__percpu_init_rwsem); > > -void percpu_free_rwsem(struct percpu_rw_semaphore *brw) > +void percpu_free_rwsem(struct percpu_rw_semaphore *sem) > { > /* > * XXX: temporary kludge. The error path in alloc_super() > * assumes that percpu_free_rwsem() is safe after kzalloc(). > */ > - if (!brw->fast_read_ctr) > + if (!sem->refcount) > return; > > - rcu_sync_dtor(&brw->rss); > - free_percpu(brw->fast_read_ctr); > - brw->fast_read_ctr = NULL; /* catch use after free bugs */ > + rcu_sync_dtor(&sem->rss); > + free_percpu(sem->refcount); > + sem->refcount = NULL; /* catch use after free bugs */ > } > EXPORT_SYMBOL_GPL(percpu_free_rwsem); > > -/* > - * This is the fast-path for down_read/up_read. If it succeeds we rely > - * on the barriers provided by rcu_sync_enter/exit; see the comments in > - * percpu_down_write() and percpu_up_write(). > - * > - * If this helper fails the callers rely on the normal rw_semaphore and > - * atomic_dec_and_test(), so in this case we have the necessary barriers. > - */ > -static bool update_fast_ctr(struct percpu_rw_semaphore *brw, unsigned int val) > +void __percpu_down_read(struct percpu_rw_semaphore *sem) > { > - bool success; > + /* > + * Due to having preemption disabled the decrement happens on > + * the same CPU as the increment, avoiding the > + * increment-on-one-CPU-and-decrement-on-another problem. > + * > + * And yes, if the reader misses the writer's assignment of > + * readers_block to sem->state, then the writer is > + * guaranteed to see the reader's increment. Conversely, any > + * readers that increment their sem->refcount after the > + * writer looks are guaranteed to see the readers_block value, > + * which in turn means that they are guaranteed to immediately > + * decrement their sem->refcount, so that it doesn't matter > + * that the writer missed them. > + */ > > - preempt_disable(); > - success = rcu_sync_is_idle(&brw->rss); > - if (likely(success)) > - __this_cpu_add(*brw->fast_read_ctr, val); > - preempt_enable(); > + smp_mb(); /* A matches D */ > > - return success; > -} > + /* > + * If !readers_block the critical section starts here, matched by the > + * release in percpu_up_write(). > + */ > + if (likely(smp_load_acquire(&sem->state) != readers_block)) > + return; > > -/* > - * Like the normal down_read() this is not recursive, the writer can > - * come after the first percpu_down_read() and create the deadlock. > - * > - * Note: returns with lock_is_held(brw->rw_sem) == T for lockdep, > - * percpu_up_read() does rwsem_release(). This pairs with the usage > - * of ->rw_sem in percpu_down/up_write(). > - */ > -void percpu_down_read(struct percpu_rw_semaphore *brw) > -{ > - might_sleep(); > - rwsem_acquire_read(&brw->rw_sem.dep_map, 0, 0, _RET_IP_); > + /* > + * Per the above comment; we still have preemption disabled and > + * will thus decrement on the same CPU as we incremented. > + */ > + __percpu_up_read(sem); > > - if (likely(update_fast_ctr(brw, +1))) > - return; > + /* > + * We either call schedule() in the wait, or we'll fall through > + * and reschedule on the preempt_enable() in percpu_down_read(). > + */ > + preempt_enable_no_resched(); > + > + /* > + * Avoid lockdep for the down/up_read() we already have them. > + */ > + __down_read(&sem->rw_sem); > + __this_cpu_inc(*sem->refcount); > + __up_read(&sem->rw_sem); > > - /* Avoid rwsem_acquire_read() and rwsem_release() */ > - __down_read(&brw->rw_sem); > - atomic_inc(&brw->slow_read_ctr); > - __up_read(&brw->rw_sem); > + preempt_disable(); > } > -EXPORT_SYMBOL_GPL(percpu_down_read); > +EXPORT_SYMBOL_GPL(__percpu_down_read); > > -int percpu_down_read_trylock(struct percpu_rw_semaphore *brw) > +int __percpu_down_read_trylock(struct percpu_rw_semaphore *sem) > { > - if (unlikely(!update_fast_ctr(brw, +1))) { > - if (!__down_read_trylock(&brw->rw_sem)) > - return 0; > - atomic_inc(&brw->slow_read_ctr); > - __up_read(&brw->rw_sem); > - } > - > - rwsem_acquire_read(&brw->rw_sem.dep_map, 0, 1, _RET_IP_); > - return 1; > + smp_mb(); /* A matches D */ > + > + if (likely(smp_load_acquire(&sem->state) != readers_block)) > + return 1; > + > + __percpu_up_read(sem); > + return 0; > } > +EXPORT_SYMBOL_GPL(__percpu_down_read_trylock); > > -void percpu_up_read(struct percpu_rw_semaphore *brw) > +void __percpu_up_read(struct percpu_rw_semaphore *sem) > { > - rwsem_release(&brw->rw_sem.dep_map, 1, _RET_IP_); > - > - if (likely(update_fast_ctr(brw, -1))) > - return; > + smp_mb(); /* B matches C */ > + /* > + * In other words, if they see our decrement (presumably to aggregate > + * zero, as that is the only time it matters) they will also see our > + * critical section. > + */ > + __this_cpu_dec(*sem->refcount); > > - /* false-positive is possible but harmless */ > - if (atomic_dec_and_test(&brw->slow_read_ctr)) > - wake_up_all(&brw->write_waitq); > + /* Prod writer to recheck readers_active */ > + wake_up(&sem->writer); > } > -EXPORT_SYMBOL_GPL(percpu_up_read); > +EXPORT_SYMBOL_GPL(__percpu_up_read); > + > +#define per_cpu_sum(var) \ > +({ \ > + typeof(var) __sum = 0; \ > + int cpu; \ > + compiletime_assert_atomic_type(__sum); \ > + for_each_possible_cpu(cpu) \ > + __sum += per_cpu(var, cpu); \ > + __sum; \ > +}) > > -static int clear_fast_ctr(struct percpu_rw_semaphore *brw) > +/* > + * Return true if the modular sum of the sem->refcount per-CPU variable is > + * zero. If this sum is zero, then it is stable due to the fact that if any > + * newly arriving readers increment a given counter, they will immediately > + * decrement that same counter. > + */ > +static bool readers_active_check(struct percpu_rw_semaphore *sem) > { > - unsigned int sum = 0; > - int cpu; > + if (per_cpu_sum(*sem->refcount) != 0) > + return false; > + > + /* > + * If we observed the decrement; ensure we see the entire critical > + * section. > + */ > > - for_each_possible_cpu(cpu) { > - sum += per_cpu(*brw->fast_read_ctr, cpu); > - per_cpu(*brw->fast_read_ctr, cpu) = 0; > - } > + smp_mb(); /* C matches B */ > > - return sum; > + return true; > } > > -void percpu_down_write(struct percpu_rw_semaphore *brw) > +void percpu_down_write(struct percpu_rw_semaphore *sem) > { > + down_write(&sem->rw_sem); > + > + /* Notify readers to take the slow path. */ > + rcu_sync_enter(&sem->rss); > + > /* > - * Make rcu_sync_is_idle() == F and thus disable the fast-path in > - * percpu_down_read() and percpu_up_read(), and wait for gp pass. > - * > - * The latter synchronises us with the preceding readers which used > - * the fast-past, so we can not miss the result of __this_cpu_add() > - * or anything else inside their criticial sections. > + * Notify new readers to block; up until now, and thus throughout the > + * longish rcu_sync_enter() above, new readers could still come in. > */ > - rcu_sync_enter(&brw->rss); > + sem->state = readers_block; > > - /* exclude other writers, and block the new readers completely */ > - down_write(&brw->rw_sem); > + smp_mb(); /* D matches A */ > > - /* nobody can use fast_read_ctr, move its sum into slow_read_ctr */ > - atomic_add(clear_fast_ctr(brw), &brw->slow_read_ctr); > + /* > + * If they don't see our writer of readers_block to sem->state, > + * then we are guaranteed to see their sem->refcount increment, and > + * therefore will wait for them. > + */ > > - /* wait for all readers to complete their percpu_up_read() */ > - wait_event(brw->write_waitq, !atomic_read(&brw->slow_read_ctr)); > + /* Wait for all now active readers to complete. */ > + wait_event(sem->writer, readers_active_check(sem)); > } > -EXPORT_SYMBOL_GPL(percpu_down_write); > > -void percpu_up_write(struct percpu_rw_semaphore *brw) > +void percpu_up_write(struct percpu_rw_semaphore *sem) > { > - /* release the lock, but the readers can't use the fast-path */ > - up_write(&brw->rw_sem); > /* > - * Enable the fast-path in percpu_down_read() and percpu_up_read() > - * but only after another gp pass; this adds the necessary barrier > - * to ensure the reader can't miss the changes done by us. > + * Signal the writer is done, no fast path yet. > + * > + * One reason that we cannot just immediately flip to readers_fast is > + * that new readers might fail to see the results of this writer's > + * critical section. > + * > + * Therefore we force it through the slow path which guarantees an > + * acquire and thereby guarantees the critical section's consistency. > + */ > + smp_store_release(&sem->state, readers_slow); > + > + /* > + * Release the write lock, this will allow readers back in the game. > + */ > + up_write(&sem->rw_sem); > + > + /* > + * Once this completes (at least one RCU grace period hence) the reader > + * fast path will be available again. Safe to use outside the exclusive > + * write lock because its counting. > */ > - rcu_sync_exit(&brw->rss); > + rcu_sync_exit(&sem->rss); > } > -EXPORT_SYMBOL_GPL(percpu_up_write); > diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c > index be922c9f3d37..48055bf629af 100644 > --- a/kernel/rcu/sync.c > +++ b/kernel/rcu/sync.c > @@ -55,6 +55,7 @@ static const struct { > .wait = rcu_barrier_bh, > __INIT_HELD(rcu_read_lock_bh_held) > }, > + [RCU_NONE] = { }, > }; > > enum { GP_IDLE = 0, GP_PENDING, GP_PASSED }; > @@ -65,6 +66,9 @@ enum { CB_IDLE = 0, CB_PENDING, CB_REPLAY }; > #ifdef CONFIG_PROVE_RCU > void rcu_sync_lockdep_assert(struct rcu_sync *rsp) > { > + if (rsp->gp_type == RCU_NONE) > + return; > + > RCU_LOCKDEP_WARN(!gp_ops[rsp->gp_type].held(), > "suspicious rcu_sync_is_idle() usage"); > } > @@ -80,6 +84,8 @@ void rcu_sync_init(struct rcu_sync *rsp, enum rcu_sync_type type) > memset(rsp, 0, sizeof(*rsp)); > init_waitqueue_head(&rsp->gp_wait); > rsp->gp_type = type; > + if (rsp->gp_type == RCU_NONE) > + rsp->gp_state = GP_PENDING; /* anything !0 */ > } > > /** > @@ -101,6 +107,9 @@ void rcu_sync_enter(struct rcu_sync *rsp) > { > bool need_wait, need_sync; > > + if (rsp->gp_type == RCU_NONE) > + return; > + > spin_lock_irq(&rsp->rss_lock); > need_wait = rsp->gp_count++; > need_sync = rsp->gp_state == GP_IDLE; > @@ -188,6 +197,9 @@ static void rcu_sync_func(struct rcu_head *rcu) > */ > void rcu_sync_exit(struct rcu_sync *rsp) > { > + if (rsp->gp_type == RCU_NONE) > + return; > + > spin_lock_irq(&rsp->rss_lock); > if (!--rsp->gp_count) { > if (rsp->cb_state == CB_IDLE) { > @@ -208,6 +220,9 @@ void rcu_sync_dtor(struct rcu_sync *rsp) > { > int cb_state; > > + if (rsp->gp_type == RCU_NONE) > + return; > + > BUG_ON(rsp->gp_count); > > spin_lock_irq(&rsp->rss_lock); > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 16:23 ` Paul E. McKenney @ 2016-07-14 16:45 ` Peter Zijlstra 2016-07-14 17:15 ` Paul E. McKenney 0 siblings, 1 reply; 67+ messages in thread From: Peter Zijlstra @ 2016-07-14 16:45 UTC (permalink / raw) To: Paul E. McKenney Cc: Tejun Heo, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Thu, Jul 14, 2016 at 09:23:55AM -0700, Paul E. McKenney wrote: > Hmmm... How does this handle the following sequence of events for > the case where we are not biased towards the reader? > > o The per-CPU rwsem is set up with RCU_NONE and readers_slow > (as opposed to readers_block). The rcu_sync ->gp_state is > GP_PENDING, which means that rcu_sync_is_idle() will always > return true. /false/, rcu_sync_is_idle() will always be false, to force us into the slowpath. > o Task A on CPU 0 runs percpu_down_read() to completion, and remains > within the critical section. CPU 0's ->refcount is therefore 1. > > o Task B on CPU 1 does percpu_down_write(), which write-acquires > ->rw_sem, does rcu_sync_enter() (which is a no-op due to > RCU_NONE), sets ->state to readers_block, and is just now going > to wait for readers, which first invokes readers_active_check(), > which starts summing the ->refcount for CPUs 0, 1, and 2, > obtaining the value 1 so far. > > o Task C CPU 2 enters percpu_down_read(), disables preemption, > increments CPU 2's ->refcount, sees rcu_sync_is_idle() return > true (so skips __percpu_down_read()), enables preemption, and > enters its critical section. false, so does __percpu_down_read() > > o Task C migrates to CPU 3 and invokes percpu_up_read(), which > disables preemption, sees rcu_sync_is_idle() return true, calls > __this_cpu_dec() on CPU 3's ->refcount, and enables preemption. > The value of CPU 3's ->refcount is thus (unsigned int)-1. __percpu_up_read() > > o Task B on CPU 1 continues execution in readers_active_check(), with > the full sum being zero. > > So it looks to me like we have Task A as a writer at the same time that > Task A is a reader, which would not be so good. > > So what am I missing here? for RCU_NONE we init rsp->gp_state to !0, which makes: static inline rcu_sync_is_idle()'s return !rsp->gp_state (aka. rsp->gp_state == 0) return false. > And a couple of checkpatch nits below. Yes, I had to apply the patch to > figure out what it was doing. ;-) Yah, too much churn to read :-) In any case, rest assured you've already gone over this part of the patch several times. I repurposed an old percpu-rwsem optimization, Oleg recognised it. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 16:45 ` Peter Zijlstra @ 2016-07-14 17:15 ` Paul E. McKenney 0 siblings, 0 replies; 67+ messages in thread From: Paul E. McKenney @ 2016-07-14 17:15 UTC (permalink / raw) To: Peter Zijlstra Cc: Tejun Heo, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Thu, Jul 14, 2016 at 06:45:47PM +0200, Peter Zijlstra wrote: > On Thu, Jul 14, 2016 at 09:23:55AM -0700, Paul E. McKenney wrote: > > Hmmm... How does this handle the following sequence of events for > > the case where we are not biased towards the reader? > > > > o The per-CPU rwsem is set up with RCU_NONE and readers_slow > > (as opposed to readers_block). The rcu_sync ->gp_state is > > GP_PENDING, which means that rcu_sync_is_idle() will always > > return true. > > /false/, rcu_sync_is_idle() will always be false, to force us into the > slowpath. Ah, got it... > > o Task A on CPU 0 runs percpu_down_read() to completion, and remains > > within the critical section. CPU 0's ->refcount is therefore 1. > > > > o Task B on CPU 1 does percpu_down_write(), which write-acquires > > ->rw_sem, does rcu_sync_enter() (which is a no-op due to > > RCU_NONE), sets ->state to readers_block, and is just now going > > to wait for readers, which first invokes readers_active_check(), > > which starts summing the ->refcount for CPUs 0, 1, and 2, > > obtaining the value 1 so far. > > > > o Task C CPU 2 enters percpu_down_read(), disables preemption, > > increments CPU 2's ->refcount, sees rcu_sync_is_idle() return > > true (so skips __percpu_down_read()), enables preemption, and > > enters its critical section. > > false, so does __percpu_down_read() > > > > > o Task C migrates to CPU 3 and invokes percpu_up_read(), which > > disables preemption, sees rcu_sync_is_idle() return true, calls > > __this_cpu_dec() on CPU 3's ->refcount, and enables preemption. > > The value of CPU 3's ->refcount is thus (unsigned int)-1. > > __percpu_up_read() > > > > > o Task B on CPU 1 continues execution in readers_active_check(), with > > the full sum being zero. > > > > So it looks to me like we have Task A as a writer at the same time that > > Task A is a reader, which would not be so good. > > > > So what am I missing here? > > for RCU_NONE we init rsp->gp_state to !0, which makes: > > static inline rcu_sync_is_idle()'s > > return !rsp->gp_state (aka. rsp->gp_state == 0) > > return false. > > > And a couple of checkpatch nits below. Yes, I had to apply the patch to > > figure out what it was doing. ;-) > > Yah, too much churn to read :-) > > In any case, rest assured you've already gone over this part of the > patch several times. I repurposed an old percpu-rwsem optimization, Oleg > recognised it. OK, in that case I will hold off pending John Stultz's performance checks. Thanx, Paul ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 13:18 ` Peter Zijlstra ` (2 preceding siblings ...) 2016-07-14 16:23 ` Paul E. McKenney @ 2016-07-14 16:43 ` John Stultz 2016-07-14 16:49 ` Peter Zijlstra 2016-07-14 18:09 ` Oleg Nesterov 4 siblings, 1 reply; 67+ messages in thread From: John Stultz @ 2016-07-14 16:43 UTC (permalink / raw) To: Peter Zijlstra Cc: Tejun Heo, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov, Paul E. McKenney On Thu, Jul 14, 2016 at 6:18 AM, Peter Zijlstra <peterz@infradead.org> wrote: > On Wed, Jul 13, 2016 at 10:51:02PM +0200, Peter Zijlstra wrote: >> So, IIRC, the trade-off is a full memory barrier in read_lock and >> read_unlock() vs sync_sched() in write. >> >> Full memory barriers are expensive and while the combined cost might >> well exceed the cost of the sync_sched() it doesn't suffer the latency >> issues. >> >> Not sure if we can frob the two in a single codebase, but I can have a >> poke if Oleg or Paul doesn't beat me to it. > > OK, not too horrible if I say so myself :-) > > The below is a compile tested only first draft so far. I'll go give it > some runtime next. Unfortunately it didn't apply cleanly to the 4.4 based tree I'm working with, so I had to manually apply the entirety of the percpu-rwsem.c changes myself. Hopefully I didn't screw it up. So running with this, I'm still seeing some pretty large delays. 80ms peak, with lots of >20ms values as well. So it doesn't seem to have the positive effect that Paul's change provided. thanks -john ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 16:43 ` John Stultz @ 2016-07-14 16:49 ` Peter Zijlstra 2016-07-14 17:02 ` John Stultz 0 siblings, 1 reply; 67+ messages in thread From: Peter Zijlstra @ 2016-07-14 16:49 UTC (permalink / raw) To: John Stultz Cc: Tejun Heo, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov, Paul E. McKenney On Thu, Jul 14, 2016 at 09:43:40AM -0700, John Stultz wrote: > On Thu, Jul 14, 2016 at 6:18 AM, Peter Zijlstra <peterz@infradead.org> wrote: > > On Wed, Jul 13, 2016 at 10:51:02PM +0200, Peter Zijlstra wrote: > >> So, IIRC, the trade-off is a full memory barrier in read_lock and > >> read_unlock() vs sync_sched() in write. > >> > >> Full memory barriers are expensive and while the combined cost might > >> well exceed the cost of the sync_sched() it doesn't suffer the latency > >> issues. > >> > >> Not sure if we can frob the two in a single codebase, but I can have a > >> poke if Oleg or Paul doesn't beat me to it. > > > > OK, not too horrible if I say so myself :-) > > > > The below is a compile tested only first draft so far. I'll go give it > > some runtime next. > > Unfortunately it didn't apply cleanly to the 4.4 based tree I'm > working with, so I had to manually apply the entirety of the > percpu-rwsem.c changes myself. Hopefully I didn't screw it up. > > So running with this, I'm still seeing some pretty large delays. 80ms > peak, with lots of >20ms values as well. > So it doesn't seem to have the positive effect that Paul's change provided. Well that is weird, did you put a tracepoint/printk in synchronize_sched() to ensure we don't end up calling that? ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 16:49 ` Peter Zijlstra @ 2016-07-14 17:02 ` John Stultz 2016-07-14 17:13 ` Oleg Nesterov 0 siblings, 1 reply; 67+ messages in thread From: John Stultz @ 2016-07-14 17:02 UTC (permalink / raw) To: Peter Zijlstra Cc: Tejun Heo, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov, Paul E. McKenney On Thu, Jul 14, 2016 at 9:49 AM, Peter Zijlstra <peterz@infradead.org> wrote: > On Thu, Jul 14, 2016 at 09:43:40AM -0700, John Stultz wrote: >> On Thu, Jul 14, 2016 at 6:18 AM, Peter Zijlstra <peterz@infradead.org> wrote: >> > On Wed, Jul 13, 2016 at 10:51:02PM +0200, Peter Zijlstra wrote: >> >> So, IIRC, the trade-off is a full memory barrier in read_lock and >> >> read_unlock() vs sync_sched() in write. >> >> >> >> Full memory barriers are expensive and while the combined cost might >> >> well exceed the cost of the sync_sched() it doesn't suffer the latency >> >> issues. >> >> >> >> Not sure if we can frob the two in a single codebase, but I can have a >> >> poke if Oleg or Paul doesn't beat me to it. >> > >> > OK, not too horrible if I say so myself :-) >> > >> > The below is a compile tested only first draft so far. I'll go give it >> > some runtime next. >> >> Unfortunately it didn't apply cleanly to the 4.4 based tree I'm >> working with, so I had to manually apply the entirety of the >> percpu-rwsem.c changes myself. Hopefully I didn't screw it up. >> >> So running with this, I'm still seeing some pretty large delays. 80ms >> peak, with lots of >20ms values as well. >> So it doesn't seem to have the positive effect that Paul's change provided. > > Well that is weird, did you put a tracepoint/printk in > synchronize_sched() to ensure we don't end up calling that? So I am seeing synchronize_sched called, and its taking the !rcu_gp_is_expedited path when I see the particularly bad latencies. I wonder if I just mucked up applying the patch? thanks -john ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 17:02 ` John Stultz @ 2016-07-14 17:13 ` Oleg Nesterov 2016-07-14 17:30 ` John Stultz 0 siblings, 1 reply; 67+ messages in thread From: Oleg Nesterov @ 2016-07-14 17:13 UTC (permalink / raw) To: John Stultz Cc: Peter Zijlstra, Tejun Heo, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Paul E. McKenney On 07/14, John Stultz wrote: > > So I am seeing synchronize_sched called, and its taking the > !rcu_gp_is_expedited path when I see the particularly bad latencies. > > I wonder if I just mucked up applying the patch? Probably yes... Just in case, could you try the patch below? Of course, without other optimizations from Peter, this change makes cgroup_threadgroup_rwsem much worse than a plain rw_semaphore. Oleg. --- x/kernel/cgroup.c +++ x/kernel/cgroup.c @@ -5605,6 +5605,8 @@ int __init cgroup_init(void) BUG_ON(cgroup_init_cftypes(NULL, cgroup_dfl_base_files)); BUG_ON(cgroup_init_cftypes(NULL, cgroup_legacy_base_files)); + rcu_sync_enter(&cgroup_threadgroup_rwsem.rss); + get_user_ns(init_cgroup_ns.user_ns); mutex_lock(&cgroup_mutex); ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 17:13 ` Oleg Nesterov @ 2016-07-14 17:30 ` John Stultz 2016-07-14 17:41 ` Oleg Nesterov 0 siblings, 1 reply; 67+ messages in thread From: John Stultz @ 2016-07-14 17:30 UTC (permalink / raw) To: Oleg Nesterov Cc: Peter Zijlstra, Tejun Heo, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Paul E. McKenney On Thu, Jul 14, 2016 at 10:13 AM, Oleg Nesterov <oleg@redhat.com> wrote: > On 07/14, John Stultz wrote: >> >> So I am seeing synchronize_sched called, and its taking the >> !rcu_gp_is_expedited path when I see the particularly bad latencies. >> >> I wonder if I just mucked up applying the patch? > > Probably yes... Hm. So I applied peterz patch to 4.7-rc7 and then diffed it to what I had and it was just whitespace changes. I've synched them up now, so I suspect my application isn't the issue now. Just to be clear, I'm not supposed to be applying this on-top of Paul's change, right? > Just in case, could you try the patch below? Of course, without other > optimizations from Peter, this change makes cgroup_threadgroup_rwsem > much worse than a plain rw_semaphore. > > Oleg. > > --- x/kernel/cgroup.c > +++ x/kernel/cgroup.c > @@ -5605,6 +5605,8 @@ int __init cgroup_init(void) > BUG_ON(cgroup_init_cftypes(NULL, cgroup_dfl_base_files)); > BUG_ON(cgroup_init_cftypes(NULL, cgroup_legacy_base_files)); > > + rcu_sync_enter(&cgroup_threadgroup_rwsem.rss); > + So adding this does make a huge difference ontop of Peter's patch. I'm seeing sub 200us values for everything. The biggest spike in my basic testing has been 138us. I'm also not seeing synchronize_sched being called nearly as often, and it doesn't seem to be being called in cgroup_procs_write path. thanks -john ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 17:30 ` John Stultz @ 2016-07-14 17:41 ` Oleg Nesterov 2016-07-14 17:51 ` John Stultz 0 siblings, 1 reply; 67+ messages in thread From: Oleg Nesterov @ 2016-07-14 17:41 UTC (permalink / raw) To: John Stultz Cc: Peter Zijlstra, Tejun Heo, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Paul E. McKenney On 07/14, John Stultz wrote: > > I'm not supposed to be applying this on-top of > Paul's change, right? Right, unless I am totally confused, > > Just in case, could you try the patch below? Of course, without other > > optimizations from Peter, this change makes cgroup_threadgroup_rwsem > > much worse than a plain rw_semaphore. > > > > Oleg. > > > > --- x/kernel/cgroup.c > > +++ x/kernel/cgroup.c > > @@ -5605,6 +5605,8 @@ int __init cgroup_init(void) > > BUG_ON(cgroup_init_cftypes(NULL, cgroup_dfl_base_files)); > > BUG_ON(cgroup_init_cftypes(NULL, cgroup_legacy_base_files)); > > > > + rcu_sync_enter(&cgroup_threadgroup_rwsem.rss); > > + > > > So adding this does make a huge difference ontop of Peter's patch. Ah, sorry for confusion. I meant, you could try this one-liner without any other changes. But we will need the "slow mode optimization" part from Peter's patch anyway, otherwise percpu_rw_semaphore simply makes no sense for cgroup_threadgroup_rwsem. Oleg. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 17:41 ` Oleg Nesterov @ 2016-07-14 17:51 ` John Stultz 0 siblings, 0 replies; 67+ messages in thread From: John Stultz @ 2016-07-14 17:51 UTC (permalink / raw) To: Oleg Nesterov Cc: Peter Zijlstra, Tejun Heo, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Paul E. McKenney On Thu, Jul 14, 2016 at 10:41 AM, Oleg Nesterov <oleg@redhat.com> wrote: > On 07/14, John Stultz wrote: >> >> I'm not supposed to be applying this on-top of >> Paul's change, right? > > Right, unless I am totally confused, > >> > Just in case, could you try the patch below? Of course, without other >> > optimizations from Peter, this change makes cgroup_threadgroup_rwsem >> > much worse than a plain rw_semaphore. >> > >> > Oleg. >> > >> > --- x/kernel/cgroup.c >> > +++ x/kernel/cgroup.c >> > @@ -5605,6 +5605,8 @@ int __init cgroup_init(void) >> > BUG_ON(cgroup_init_cftypes(NULL, cgroup_dfl_base_files)); >> > BUG_ON(cgroup_init_cftypes(NULL, cgroup_legacy_base_files)); >> > >> > + rcu_sync_enter(&cgroup_threadgroup_rwsem.rss); >> > + >> >> >> So adding this does make a huge difference ontop of Peter's patch. > > Ah, sorry for confusion. I meant, you could try this one-liner without > any other changes. So the one-liner without other changes helps at a similar level as Paul's change. From some simple testing I've got a 3.5ms spike, but otherwise the values are under 200us. > But we will need the "slow mode optimization" part from Peter's patch > anyway, otherwise percpu_rw_semaphore simply makes no sense for > cgroup_threadgroup_rwsem. Yea, with Peter's patch it is further improved. thanks -john ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 13:18 ` Peter Zijlstra ` (3 preceding siblings ...) 2016-07-14 16:43 ` John Stultz @ 2016-07-14 18:09 ` Oleg Nesterov 2016-07-14 18:36 ` Peter Zijlstra 4 siblings, 1 reply; 67+ messages in thread From: Oleg Nesterov @ 2016-07-14 18:09 UTC (permalink / raw) To: Peter Zijlstra Cc: Tejun Heo, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Paul E. McKenney On 07/14, Peter Zijlstra wrote: > > The below is a compile tested only first draft so far. I'll go give it > some runtime next. So I will wait for the new version, but at first glance this matches the code I already reviewed in the past (at least, tried hard to review ;) and it looks correct. Just a couple of almost cosmetic nits, feel free to ignore. > --- a/include/linux/percpu-rwsem.h > +++ b/include/linux/percpu-rwsem.h > @@ -10,29 +10,107 @@ > > struct percpu_rw_semaphore { > struct rcu_sync rss; > - unsigned int __percpu *fast_read_ctr; > + unsigned int __percpu *refcount; > struct rw_semaphore rw_sem; > - atomic_t slow_read_ctr; > - wait_queue_head_t write_waitq; > + wait_queue_head_t writer; > + int state; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think that this "int state" and "enum { readers_slow, readers_block }" just add a bit of complication/confusion. All we need is the simple "bool readers_block" in percpu_rw_semaphore, no? > +void percpu_down_write(struct percpu_rw_semaphore *sem) > { > + down_write(&sem->rw_sem); > + > + /* Notify readers to take the slow path. */ > + rcu_sync_enter(&sem->rss); I'd suggest to call rcu_sync_enter() before down_write(). This can help when we wait for another writer which holds this lock. Oleg. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 18:09 ` Oleg Nesterov @ 2016-07-14 18:36 ` Peter Zijlstra 2016-07-14 19:35 ` Peter Zijlstra 0 siblings, 1 reply; 67+ messages in thread From: Peter Zijlstra @ 2016-07-14 18:36 UTC (permalink / raw) To: Oleg Nesterov Cc: Tejun Heo, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Paul E. McKenney On Thu, Jul 14, 2016 at 08:09:52PM +0200, Oleg Nesterov wrote: > On 07/14, Peter Zijlstra wrote: > > > > The below is a compile tested only first draft so far. I'll go give it > > some runtime next. > > So I will wait for the new version, but at first glance this matches the > code I already reviewed in the past (at least, tried hard to review ;) > and it looks correct. > > Just a couple of almost cosmetic nits, feel free to ignore. Drat, I just mailed out the patches.. I can do a second version later. > > --- a/include/linux/percpu-rwsem.h > > +++ b/include/linux/percpu-rwsem.h > > @@ -10,29 +10,107 @@ > > > > struct percpu_rw_semaphore { > > struct rcu_sync rss; > > - unsigned int __percpu *fast_read_ctr; > > + unsigned int __percpu *refcount; > > struct rw_semaphore rw_sem; > > - atomic_t slow_read_ctr; > > - wait_queue_head_t write_waitq; > > + wait_queue_head_t writer; > > + int state; > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I think that this "int state" and "enum { readers_slow, readers_block }" > just add a bit of complication/confusion. > > All we need is the simple "bool readers_block" in percpu_rw_semaphore, > no? So I detest bool in structures because sizeof(bool) isn't defined. Obviously an implementation needs to pick a size, but this is typically architecture ABIs, so sizes can differ between architectures. But yes, I suppose "int readers_block" will do just fine. IIRC, earlier version had more states, but that all went away. > > +void percpu_down_write(struct percpu_rw_semaphore *sem) > > { > > + down_write(&sem->rw_sem); > > + > > + /* Notify readers to take the slow path. */ > > + rcu_sync_enter(&sem->rss); > > I'd suggest to call rcu_sync_enter() before down_write(). This can help > when we wait for another writer which holds this lock. Hurm, I think I figured that might have issues, but I cannot seem to think of any just now :-), yes can do. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-14 18:36 ` Peter Zijlstra @ 2016-07-14 19:35 ` Peter Zijlstra 0 siblings, 0 replies; 67+ messages in thread From: Peter Zijlstra @ 2016-07-14 19:35 UTC (permalink / raw) To: Oleg Nesterov Cc: Tejun Heo, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Paul E. McKenney On Thu, Jul 14, 2016 at 08:36:09PM +0200, Peter Zijlstra wrote: > On Thu, Jul 14, 2016 at 08:09:52PM +0200, Oleg Nesterov wrote: > > On 07/14, Peter Zijlstra wrote: > > > > > > The below is a compile tested only first draft so far. I'll go give it > > > some runtime next. > > > > So I will wait for the new version, but at first glance this matches the > > code I already reviewed in the past (at least, tried hard to review ;) > > and it looks correct. > > > > Just a couple of almost cosmetic nits, feel free to ignore. > > Drat, I just mailed out the patches.. I can do a second version later. How about so on top of what I sent? --- a/include/linux/percpu-rwsem.h +++ b/include/linux/percpu-rwsem.h @@ -13,11 +13,10 @@ struct percpu_rw_semaphore { unsigned int __percpu *read_count; struct rw_semaphore rw_sem; wait_queue_head_t writer; - int state; + int readers_block; }; -extern void __percpu_down_read(struct percpu_rw_semaphore *); -extern int __percpu_down_read_trylock(struct percpu_rw_semaphore *); +extern int __percpu_down_read(struct percpu_rw_semaphore *, int); extern void __percpu_up_read(struct percpu_rw_semaphore *); static inline void percpu_down_read(struct percpu_rw_semaphore *sem) @@ -37,7 +36,7 @@ static inline void percpu_down_read(stru */ __this_cpu_inc(*sem->read_count); if (unlikely(!rcu_sync_is_idle(&sem->rss))) - __percpu_down_read(sem); /* Unconditional memory barrier */ + __percpu_down_read(sem, false); /* Unconditional memory barrier */ preempt_enable(); /* * The barrier() from preempt_enable() prevents the compiler from @@ -55,7 +54,7 @@ static inline int percpu_down_read_trylo */ __this_cpu_inc(*sem->read_count); if (unlikely(!rcu_sync_is_idle(&sem->rss))) - ret = __percpu_down_read_trylock(sem); + ret = __percpu_down_read(sem, true); /* Unconditional memory barrier */ preempt_enable(); /* * The barrier() from preempt_enable() prevents the compiler from --- a/kernel/locking/percpu-rwsem.c +++ b/kernel/locking/percpu-rwsem.c @@ -8,8 +8,6 @@ #include <linux/sched.h> #include <linux/errno.h> -enum { readers_slow, readers_block }; - int __percpu_init_rwsem(struct percpu_rw_semaphore *sem, const char *name, struct lock_class_key *rwsem_key) { @@ -21,7 +19,7 @@ int __percpu_init_rwsem(struct percpu_rw rcu_sync_init(&sem->rss, RCU_SCHED_SYNC); __init_rwsem(&sem->rw_sem, name, rwsem_key); init_waitqueue_head(&sem->writer); - sem->state = readers_slow; + sem->readers_block = 0; return 0; } EXPORT_SYMBOL_GPL(__percpu_init_rwsem); @@ -41,21 +39,21 @@ void percpu_free_rwsem(struct percpu_rw_ } EXPORT_SYMBOL_GPL(percpu_free_rwsem); -void __percpu_down_read(struct percpu_rw_semaphore *sem) +int __percpu_down_read(struct percpu_rw_semaphore *sem, int try) { /* * Due to having preemption disabled the decrement happens on * the same CPU as the increment, avoiding the * increment-on-one-CPU-and-decrement-on-another problem. * - * And yes, if the reader misses the writer's assignment of - * readers_block to sem->state, then the writer is - * guaranteed to see the reader's increment. Conversely, any - * readers that increment their sem->read_count after the - * writer looks are guaranteed to see the readers_block value, + * If the reader misses the writer's assignment of readers_block, then + * the writer is guaranteed to see the reader's increment. + * + * Conversely, any readers that increment their sem->read_count after + * the writer looks are guaranteed to see the readers_block value, * which in turn means that they are guaranteed to immediately - * decrement their sem->read_count, so that it doesn't matter - * that the writer missed them. + * decrement their sem->read_count, so that it doesn't matter that the + * writer missed them. */ smp_mb(); /* A matches D */ @@ -64,8 +62,8 @@ void __percpu_down_read(struct percpu_rw * If !readers_block the critical section starts here, matched by the * release in percpu_up_write(). */ - if (likely(smp_load_acquire(&sem->state) != readers_block)) - return; + if (likely(!smp_load_acquire(&sem->readers_block))) + return 1; /* * Per the above comment; we still have preemption disabled and @@ -73,6 +71,9 @@ void __percpu_down_read(struct percpu_rw */ __percpu_up_read(sem); + if (try) + return 0; + /* * We either call schedule() in the wait, or we'll fall through * and reschedule on the preempt_enable() in percpu_down_read(). @@ -87,21 +88,10 @@ void __percpu_down_read(struct percpu_rw __up_read(&sem->rw_sem); preempt_disable(); + return 1; } EXPORT_SYMBOL_GPL(__percpu_down_read); -int __percpu_down_read_trylock(struct percpu_rw_semaphore *sem) -{ - smp_mb(); /* A matches D */ - - if (likely(smp_load_acquire(&sem->state) != readers_block)) - return 1; - - __percpu_up_read(sem); - return 0; -} -EXPORT_SYMBOL_GPL(__percpu_down_read_trylock); - void __percpu_up_read(struct percpu_rw_semaphore *sem) { smp_mb(); /* B matches C */ @@ -150,23 +140,23 @@ static bool readers_active_check(struct void percpu_down_write(struct percpu_rw_semaphore *sem) { - down_write(&sem->rw_sem); - /* Notify readers to take the slow path. */ rcu_sync_enter(&sem->rss); + down_write(&sem->rw_sem); + /* * Notify new readers to block; up until now, and thus throughout the * longish rcu_sync_enter() above, new readers could still come in. */ - WRITE_ONCE(sem->state, readers_block); + WRITE_ONCE(sem->readers_block, 1); smp_mb(); /* D matches A */ /* - * If they don't see our writer of readers_block to sem->state, - * then we are guaranteed to see their sem->read_count increment, and - * therefore will wait for them. + * If they don't see our writer of readers_block, then we are + * guaranteed to see their sem->read_count increment, and therefore + * will wait for them. */ /* Wait for all now active readers to complete. */ @@ -186,7 +176,7 @@ void percpu_up_write(struct percpu_rw_se * Therefore we force it through the slow path which guarantees an * acquire and thereby guarantees the critical section's consistency. */ - smp_store_release(&sem->state, readers_slow); + smp_store_release(&sem->readers_block, 0); /* * Release the write lock, this will allow readers back in the game. @@ -194,9 +184,9 @@ void percpu_up_write(struct percpu_rw_se up_write(&sem->rw_sem); /* - * Once this completes (at least one RCU grace period hence) the reader - * fast path will be available again. Safe to use outside the exclusive - * write lock because its counting. + * Once this completes (at least one RCU-sched grace period hence) the + * reader fast path will be available again. Safe to use outside the + * exclusive write lock because its counting. */ rcu_sync_exit(&sem->rss); } ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 20:39 ` Tejun Heo 2016-07-13 20:51 ` Peter Zijlstra @ 2016-07-13 20:57 ` John Stultz 1 sibling, 0 replies; 67+ messages in thread From: John Stultz @ 2016-07-13 20:57 UTC (permalink / raw) To: Tejun Heo Cc: Peter Zijlstra, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov, Paul E. McKenney On Wed, Jul 13, 2016 at 1:39 PM, Tejun Heo <tj@kernel.org> wrote: > Hello, > > On Wed, Jul 13, 2016 at 10:26:57PM +0200, Peter Zijlstra wrote: >> > So, it's a percpu rwsem issue then. I haven't really followed the >> > perpcpu rwsem changes closely. Oleg, are multi-milisec delay expected >> > on down write expected with the current implementation of >> > percpu_rwsem? >> >> There is a synchronize_sched() in there, so sorta. That thing is heavily >> geared towards readers, as is the only 'sane' choice for global locks. > > It used to use the expedited variant until 001dac627ff3 > ("locking/percpu-rwsem: Make use of the rcu_sync infrastructure"), so > it might have been okay before then. Just as a datapoint, just reverting 001dac627ff3 ("locking/percpu-rwsem: Make use of the rcu_sync infrastructure"), doesn't seem to help as much as your prior patch going to a normal rwsem. I'm consistently seeing values in the 100-550us range (with occasional spikes around 6ms), with a max value at 36ms. thanks -john ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 20:26 ` Peter Zijlstra 2016-07-13 20:39 ` Tejun Heo @ 2016-07-13 20:52 ` Paul E. McKenney 2016-07-13 20:57 ` Peter Zijlstra 2016-07-13 21:01 ` Dmitry Shmidt 1 sibling, 2 replies; 67+ messages in thread From: Paul E. McKenney @ 2016-07-13 20:52 UTC (permalink / raw) To: Peter Zijlstra Cc: Tejun Heo, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 10:26:57PM +0200, Peter Zijlstra wrote: > On Wed, Jul 13, 2016 at 04:18:23PM -0400, Tejun Heo wrote: > > Hello, John. > > > > On Wed, Jul 13, 2016 at 01:13:11PM -0700, John Stultz wrote: > > > On Wed, Jul 13, 2016 at 11:33 AM, Tejun Heo <tj@kernel.org> wrote: > > > > On Wed, Jul 13, 2016 at 02:21:02PM -0400, Tejun Heo wrote: > > > >> One interesting thing to try would be replacing it with a regular > > > >> non-percpu rwsem and see how it behaves. That should easily tell us > > > >> whether this is from actual contention or artifacts from percpu_rwsem > > > >> implementation. > > > > > > > > So, something like the following. Can you please see whether this > > > > makes any difference? > > > > > > Yea. So this brings it down for me closer to what we're seeing with > > > the Dmitry's patch reverting the two problematic commits, usually > > > 10-50us with one early spike at 18ms. > > > > So, it's a percpu rwsem issue then. I haven't really followed the > > perpcpu rwsem changes closely. Oleg, are multi-milisec delay expected > > on down write expected with the current implementation of > > percpu_rwsem? > > There is a synchronize_sched() in there, so sorta. That thing is heavily > geared towards readers, as is the only 'sane' choice for global locks. Then one diagnostic step to take would be to replace that synchronize_sched() with synchronize_sched_expedited(), and see if that gets rid of the delays. Not a particularly real-time-friendly fix, but certainly a good check on our various assumptions. Thanx, Paul ------------------------------------------------------------------------ diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c index be922c9f3d37..211acddc7e21 100644 --- a/kernel/rcu/sync.c +++ b/kernel/rcu/sync.c @@ -38,19 +38,19 @@ static const struct { #endif } gp_ops[] = { [RCU_SYNC] = { - .sync = synchronize_rcu, + .sync = synchronize_rcu_expedited, .call = call_rcu, .wait = rcu_barrier, __INIT_HELD(rcu_read_lock_held) }, [RCU_SCHED_SYNC] = { - .sync = synchronize_sched, + .sync = synchronize_sched_expedited, .call = call_rcu_sched, .wait = rcu_barrier_sched, __INIT_HELD(rcu_read_lock_sched_held) }, [RCU_BH_SYNC] = { - .sync = synchronize_rcu_bh, + .sync = synchronize_rcu_bh_expedited, .call = call_rcu_bh, .wait = rcu_barrier_bh, __INIT_HELD(rcu_read_lock_bh_held) ^ permalink raw reply related [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 20:52 ` Paul E. McKenney @ 2016-07-13 20:57 ` Peter Zijlstra 2016-07-13 21:08 ` Paul E. McKenney 2016-07-13 21:01 ` Dmitry Shmidt 1 sibling, 1 reply; 67+ messages in thread From: Peter Zijlstra @ 2016-07-13 20:57 UTC (permalink / raw) To: Paul E. McKenney Cc: Tejun Heo, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 01:52:11PM -0700, Paul E. McKenney wrote: > Not a particularly real-time-friendly fix, but certainly a good check > on our various assumptions. Not only RT, but also HPC and all the other RDMA userspace polling freaks ;-) But yes, it would confirm that this is indeed the issue. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 20:57 ` Peter Zijlstra @ 2016-07-13 21:08 ` Paul E. McKenney 0 siblings, 0 replies; 67+ messages in thread From: Paul E. McKenney @ 2016-07-13 21:08 UTC (permalink / raw) To: Peter Zijlstra Cc: Tejun Heo, John Stultz, Ingo Molnar, lkml, Dmitry Shmidt, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 10:57:12PM +0200, Peter Zijlstra wrote: > On Wed, Jul 13, 2016 at 01:52:11PM -0700, Paul E. McKenney wrote: > > Not a particularly real-time-friendly fix, but certainly a good check > > on our various assumptions. > > Not only RT, but also HPC and all the other RDMA userspace polling > freaks ;-) If Tejun's lglock-like approach doesn't pan out, then it would quite easy to make a boot parameter that selected expedited vs. non-expedited behavior. Thanx, Paul ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 20:52 ` Paul E. McKenney 2016-07-13 20:57 ` Peter Zijlstra @ 2016-07-13 21:01 ` Dmitry Shmidt 2016-07-13 21:03 ` John Stultz 2016-07-13 21:05 ` Paul E. McKenney 1 sibling, 2 replies; 67+ messages in thread From: Dmitry Shmidt @ 2016-07-13 21:01 UTC (permalink / raw) To: Paul McKenney Cc: Peter Zijlstra, Tejun Heo, John Stultz, Ingo Molnar, lkml, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 1:52 PM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > On Wed, Jul 13, 2016 at 10:26:57PM +0200, Peter Zijlstra wrote: >> On Wed, Jul 13, 2016 at 04:18:23PM -0400, Tejun Heo wrote: >> > Hello, John. >> > >> > On Wed, Jul 13, 2016 at 01:13:11PM -0700, John Stultz wrote: >> > > On Wed, Jul 13, 2016 at 11:33 AM, Tejun Heo <tj@kernel.org> wrote: >> > > > On Wed, Jul 13, 2016 at 02:21:02PM -0400, Tejun Heo wrote: >> > > >> One interesting thing to try would be replacing it with a regular >> > > >> non-percpu rwsem and see how it behaves. That should easily tell us >> > > >> whether this is from actual contention or artifacts from percpu_rwsem >> > > >> implementation. >> > > > >> > > > So, something like the following. Can you please see whether this >> > > > makes any difference? >> > > >> > > Yea. So this brings it down for me closer to what we're seeing with >> > > the Dmitry's patch reverting the two problematic commits, usually >> > > 10-50us with one early spike at 18ms. >> > >> > So, it's a percpu rwsem issue then. I haven't really followed the >> > perpcpu rwsem changes closely. Oleg, are multi-milisec delay expected >> > on down write expected with the current implementation of >> > percpu_rwsem? >> >> There is a synchronize_sched() in there, so sorta. That thing is heavily >> geared towards readers, as is the only 'sane' choice for global locks. > > Then one diagnostic step to take would be to replace that > synchronize_sched() with synchronize_sched_expedited(), and see if that > gets rid of the delays. > > Not a particularly real-time-friendly fix, but certainly a good check > on our various assumptions. All delays <200 us, but one that is 3 ms. > Thanx, Paul > > ------------------------------------------------------------------------ > > diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c > index be922c9f3d37..211acddc7e21 100644 > --- a/kernel/rcu/sync.c > +++ b/kernel/rcu/sync.c > @@ -38,19 +38,19 @@ static const struct { > #endif > } gp_ops[] = { > [RCU_SYNC] = { > - .sync = synchronize_rcu, > + .sync = synchronize_rcu_expedited, > .call = call_rcu, > .wait = rcu_barrier, > __INIT_HELD(rcu_read_lock_held) > }, > [RCU_SCHED_SYNC] = { > - .sync = synchronize_sched, > + .sync = synchronize_sched_expedited, > .call = call_rcu_sched, > .wait = rcu_barrier_sched, > __INIT_HELD(rcu_read_lock_sched_held) > }, > [RCU_BH_SYNC] = { > - .sync = synchronize_rcu_bh, > + .sync = synchronize_rcu_bh_expedited, > .call = call_rcu_bh, > .wait = rcu_barrier_bh, > __INIT_HELD(rcu_read_lock_bh_held) > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 21:01 ` Dmitry Shmidt @ 2016-07-13 21:03 ` John Stultz 2016-07-13 21:05 ` Paul E. McKenney 1 sibling, 0 replies; 67+ messages in thread From: John Stultz @ 2016-07-13 21:03 UTC (permalink / raw) To: Dmitry Shmidt Cc: Paul McKenney, Peter Zijlstra, Tejun Heo, Ingo Molnar, lkml, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 2:01 PM, Dmitry Shmidt <dimitrysh@google.com> wrote: > On Wed, Jul 13, 2016 at 1:52 PM, Paul E. McKenney > <paulmck@linux.vnet.ibm.com> wrote: >> On Wed, Jul 13, 2016 at 10:26:57PM +0200, Peter Zijlstra wrote: >>> On Wed, Jul 13, 2016 at 04:18:23PM -0400, Tejun Heo wrote: >>> > Hello, John. >>> > >>> > On Wed, Jul 13, 2016 at 01:13:11PM -0700, John Stultz wrote: >>> > > On Wed, Jul 13, 2016 at 11:33 AM, Tejun Heo <tj@kernel.org> wrote: >>> > > > On Wed, Jul 13, 2016 at 02:21:02PM -0400, Tejun Heo wrote: >>> > > >> One interesting thing to try would be replacing it with a regular >>> > > >> non-percpu rwsem and see how it behaves. That should easily tell us >>> > > >> whether this is from actual contention or artifacts from percpu_rwsem >>> > > >> implementation. >>> > > > >>> > > > So, something like the following. Can you please see whether this >>> > > > makes any difference? >>> > > >>> > > Yea. So this brings it down for me closer to what we're seeing with >>> > > the Dmitry's patch reverting the two problematic commits, usually >>> > > 10-50us with one early spike at 18ms. >>> > >>> > So, it's a percpu rwsem issue then. I haven't really followed the >>> > perpcpu rwsem changes closely. Oleg, are multi-milisec delay expected >>> > on down write expected with the current implementation of >>> > percpu_rwsem? >>> >>> There is a synchronize_sched() in there, so sorta. That thing is heavily >>> geared towards readers, as is the only 'sane' choice for global locks. >> >> Then one diagnostic step to take would be to replace that >> synchronize_sched() with synchronize_sched_expedited(), and see if that >> gets rid of the delays. >> >> Not a particularly real-time-friendly fix, but certainly a good check >> on our various assumptions. > > All delays <200 us, but one that is 3 ms. Yep. I'm seeing the same here too with Paul's change. thanks -john ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 21:01 ` Dmitry Shmidt 2016-07-13 21:03 ` John Stultz @ 2016-07-13 21:05 ` Paul E. McKenney 1 sibling, 0 replies; 67+ messages in thread From: Paul E. McKenney @ 2016-07-13 21:05 UTC (permalink / raw) To: Dmitry Shmidt Cc: Peter Zijlstra, Tejun Heo, John Stultz, Ingo Molnar, lkml, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 02:01:27PM -0700, Dmitry Shmidt wrote: > On Wed, Jul 13, 2016 at 1:52 PM, Paul E. McKenney > <paulmck@linux.vnet.ibm.com> wrote: > > On Wed, Jul 13, 2016 at 10:26:57PM +0200, Peter Zijlstra wrote: > >> On Wed, Jul 13, 2016 at 04:18:23PM -0400, Tejun Heo wrote: > >> > Hello, John. > >> > > >> > On Wed, Jul 13, 2016 at 01:13:11PM -0700, John Stultz wrote: > >> > > On Wed, Jul 13, 2016 at 11:33 AM, Tejun Heo <tj@kernel.org> wrote: > >> > > > On Wed, Jul 13, 2016 at 02:21:02PM -0400, Tejun Heo wrote: > >> > > >> One interesting thing to try would be replacing it with a regular > >> > > >> non-percpu rwsem and see how it behaves. That should easily tell us > >> > > >> whether this is from actual contention or artifacts from percpu_rwsem > >> > > >> implementation. > >> > > > > >> > > > So, something like the following. Can you please see whether this > >> > > > makes any difference? > >> > > > >> > > Yea. So this brings it down for me closer to what we're seeing with > >> > > the Dmitry's patch reverting the two problematic commits, usually > >> > > 10-50us with one early spike at 18ms. > >> > > >> > So, it's a percpu rwsem issue then. I haven't really followed the > >> > perpcpu rwsem changes closely. Oleg, are multi-milisec delay expected > >> > on down write expected with the current implementation of > >> > percpu_rwsem? > >> > >> There is a synchronize_sched() in there, so sorta. That thing is heavily > >> geared towards readers, as is the only 'sane' choice for global locks. > > > > Then one diagnostic step to take would be to replace that > > synchronize_sched() with synchronize_sched_expedited(), and see if that > > gets rid of the delays. > > > > Not a particularly real-time-friendly fix, but certainly a good check > > on our various assumptions. > > All delays <200 us, but one that is 3 ms. That does indicate that synchronize_sched() is the latency culprit. Tejun's lglock-like approach seems to me to be the next thing to try. Thanx, Paul > > ------------------------------------------------------------------------ > > > > diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c > > index be922c9f3d37..211acddc7e21 100644 > > --- a/kernel/rcu/sync.c > > +++ b/kernel/rcu/sync.c > > @@ -38,19 +38,19 @@ static const struct { > > #endif > > } gp_ops[] = { > > [RCU_SYNC] = { > > - .sync = synchronize_rcu, > > + .sync = synchronize_rcu_expedited, > > .call = call_rcu, > > .wait = rcu_barrier, > > __INIT_HELD(rcu_read_lock_held) > > }, > > [RCU_SCHED_SYNC] = { > > - .sync = synchronize_sched, > > + .sync = synchronize_sched_expedited, > > .call = call_rcu_sched, > > .wait = rcu_barrier_sched, > > __INIT_HELD(rcu_read_lock_sched_held) > > }, > > [RCU_BH_SYNC] = { > > - .sync = synchronize_rcu_bh, > > + .sync = synchronize_rcu_bh_expedited, > > .call = call_rcu_bh, > > .wait = rcu_barrier_bh, > > __INIT_HELD(rcu_read_lock_bh_held) > > > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 18:33 ` Tejun Heo 2016-07-13 20:13 ` John Stultz @ 2016-07-13 20:31 ` Dmitry Shmidt 1 sibling, 0 replies; 67+ messages in thread From: Dmitry Shmidt @ 2016-07-13 20:31 UTC (permalink / raw) To: Tejun Heo Cc: John Stultz, Ingo Molnar, Peter Zijlstra, lkml, Rom Lemarchand, Colin Cross, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 11:33 AM, Tejun Heo <tj@kernel.org> wrote: > On Wed, Jul 13, 2016 at 02:21:02PM -0400, Tejun Heo wrote: >> One interesting thing to try would be replacing it with a regular >> non-percpu rwsem and see how it behaves. That should easily tell us >> whether this is from actual contention or artifacts from percpu_rwsem >> implementation. > > So, something like the following. Can you please see whether this > makes any difference? It is making difference. We need to conduct more tests, but it looks much better. I see only one 18.5 ms delay. Most of time it is <200 us delay. > Thanks. > > diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h > index 5b17de6..bc1e4d8 100644 > --- a/include/linux/cgroup-defs.h > +++ b/include/linux/cgroup-defs.h > @@ -14,7 +14,7 @@ > #include <linux/mutex.h> > #include <linux/rcupdate.h> > #include <linux/percpu-refcount.h> > -#include <linux/percpu-rwsem.h> > +#include <linux/rwsem.h> > #include <linux/workqueue.h> > > #ifdef CONFIG_CGROUPS > @@ -518,7 +518,7 @@ struct cgroup_subsys { > unsigned int depends_on; > }; > > -extern struct percpu_rw_semaphore cgroup_threadgroup_rwsem; > +extern struct rw_semaphore cgroup_threadgroup_rwsem; > > /** > * cgroup_threadgroup_change_begin - threadgroup exclusion for cgroups > @@ -529,7 +529,7 @@ extern struct percpu_rw_semaphore cgroup_threadgroup_rwsem; > */ > static inline void cgroup_threadgroup_change_begin(struct task_struct *tsk) > { > - percpu_down_read(&cgroup_threadgroup_rwsem); > + down_read(&cgroup_threadgroup_rwsem); > } > > /** > @@ -541,7 +541,7 @@ static inline void cgroup_threadgroup_change_begin(struct task_struct *tsk) > */ > static inline void cgroup_threadgroup_change_end(struct task_struct *tsk) > { > - percpu_up_read(&cgroup_threadgroup_rwsem); > + up_read(&cgroup_threadgroup_rwsem); > } > > #else /* CONFIG_CGROUPS */ > diff --git a/kernel/cgroup.c b/kernel/cgroup.c > index 86cb5c6..ed9c142 100644 > --- a/kernel/cgroup.c > +++ b/kernel/cgroup.c > @@ -113,7 +113,7 @@ static DEFINE_SPINLOCK(cgroup_file_kn_lock); > */ > static DEFINE_SPINLOCK(release_agent_path_lock); > > -struct percpu_rw_semaphore cgroup_threadgroup_rwsem; > +DECLARE_RWSEM(cgroup_threadgroup_rwsem); > > #define cgroup_assert_mutex_or_rcu_locked() \ > RCU_LOCKDEP_WARN(!rcu_read_lock_held() && \ > @@ -2899,7 +2899,7 @@ static ssize_t __cgroup_procs_write(struct kernfs_open_file *of, char *buf, > if (!cgrp) > return -ENODEV; > > - percpu_down_write(&cgroup_threadgroup_rwsem); > + down_write(&cgroup_threadgroup_rwsem); > rcu_read_lock(); > if (pid) { > tsk = find_task_by_vpid(pid); > @@ -2937,7 +2937,7 @@ static ssize_t __cgroup_procs_write(struct kernfs_open_file *of, char *buf, > out_unlock_rcu: > rcu_read_unlock(); > out_unlock_threadgroup: > - percpu_up_write(&cgroup_threadgroup_rwsem); > + up_write(&cgroup_threadgroup_rwsem); > for_each_subsys(ss, ssid) > if (ss->post_attach) > ss->post_attach(); > @@ -3077,7 +3077,7 @@ static int cgroup_update_dfl_csses(struct cgroup *cgrp) > > lockdep_assert_held(&cgroup_mutex); > > - percpu_down_write(&cgroup_threadgroup_rwsem); > + down_write(&cgroup_threadgroup_rwsem); > > /* look up all csses currently attached to @cgrp's subtree */ > spin_lock_bh(&css_set_lock); > @@ -3112,7 +3112,7 @@ static int cgroup_update_dfl_csses(struct cgroup *cgrp) > ret = cgroup_taskset_migrate(&tset, cgrp->root); > out_finish: > cgroup_migrate_finish(&preloaded_csets); > - percpu_up_write(&cgroup_threadgroup_rwsem); > + up_write(&cgroup_threadgroup_rwsem); > return ret; > } > > @@ -5601,7 +5601,7 @@ int __init cgroup_init(void) > int ssid; > > BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16); > - BUG_ON(percpu_init_rwsem(&cgroup_threadgroup_rwsem)); > + //BUG_ON(percpu_init_rwsem(&cgroup_threadgroup_rwsem)); > BUG_ON(cgroup_init_cftypes(NULL, cgroup_dfl_base_files)); > BUG_ON(cgroup_init_cftypes(NULL, cgroup_legacy_base_files)); > ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 18:21 ` Tejun Heo 2016-07-13 18:33 ` Tejun Heo @ 2016-07-13 20:44 ` Colin Cross 2016-07-13 20:54 ` Tejun Heo 1 sibling, 1 reply; 67+ messages in thread From: Colin Cross @ 2016-07-13 20:44 UTC (permalink / raw) To: Tejun Heo Cc: John Stultz, Ingo Molnar, Peter Zijlstra, lkml, Dmitry Shmidt, Rom Lemarchand, Todd Kjos, Oleg Nesterov On Wed, Jul 13, 2016 at 11:21 AM, Tejun Heo <tj@kernel.org> wrote: > (cc'ing Oleg) > > Hello, > > On Tue, Jul 12, 2016 at 05:00:04PM -0700, John Stultz wrote: >> So Dmitry Shmidt recently noticed that with 4.4 based systems we're >> seeing quite a bit of performance overhead from >> __cgroup_procs_write(). >> >> With 4.4 tree as it stands, we're seeing __cgroup_procs_write() quite >> often take 10s of miliseconds to execute (with max times up in the >> 80ms range). > > Yikes, that's pretty high. Does this happen only while the system is > generally busy or regardless of overall load? > >> While with 4.1 it was quite often in the single usec range, and max >> time values still in in sub-milisecond range. >> >> The majority of these performance regressions seem to come from the >> locking changes in: >> >> 3014dde762f6 ("cgroup: simplify threadgroup locking") >> and >> 1ed1328792ff ("sched, cgroup: replace signal_struct->group_rwsem with >> a global percpu_rwsem") >> >> Dmitry has found that by reverting these two changes (which don't >> revert easiliy), we can get back down to tens 10-100 usec range for >> most calls, with max values occasionally spiking to ~18ms. >> >> Those two commits do talk about performance regressions, that were >> supposedly alleviated by percpu_rwsem changes, but I'm not sure we are >> seeing this. >> >> In 1ed1328792ff, the commit talks about the write path being a fairly >> cold path, but with Android I worry this may not actually be the case, >> as Android uses cpuset cgroups to group tasks into foreground and >> background tasks, but this means when switching applications, tasks >> are migrated between cgroups. Putting an additional 80 milisecond >> delay on this adds potentially visible latencies on task switching. > > Switching between foreground and background isn't a hot path. It's > human initiated operations after all. It taking 80 msecs sure is > problematic but I'm skeptical that this is from actual contention > given that the only reader side holders are fork and exit paths. Slight correction here, we move tasks to the foreground cgroup and back around binder IPC calls from foreground processes to background processes, so it is significantly hotter than just human initiated operations. >> Reverting those two changes in the Android common.git tree doesn't >> feel like a good long term solution here, so I was wondering if you >> had any thoughts on how to further reduce the performance regression >> here? > > One interesting thing to try would be replacing it with a regular > non-percpu rwsem and see how it behaves. That should easily tell us > whether this is from actual contention or artifacts from percpu_rwsem > implementation. > > Thanks. > > -- > tejun ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes 2016-07-13 20:44 ` Colin Cross @ 2016-07-13 20:54 ` Tejun Heo 0 siblings, 0 replies; 67+ messages in thread From: Tejun Heo @ 2016-07-13 20:54 UTC (permalink / raw) To: Colin Cross Cc: John Stultz, Ingo Molnar, Peter Zijlstra, lkml, Dmitry Shmidt, Rom Lemarchand, Todd Kjos, Oleg Nesterov Hello, On Wed, Jul 13, 2016 at 01:44:50PM -0700, Colin Cross wrote: > > Switching between foreground and background isn't a hot path. It's > > human initiated operations after all. It taking 80 msecs sure is > > problematic but I'm skeptical that this is from actual contention > > given that the only reader side holders are fork and exit paths. > > Slight correction here, we move tasks to the foreground cgroup and > back around binder IPC calls from foreground processes to background > processes, so it is significantly hotter than just human initiated > operations. Oh I see. That's extreme and you would be paying in terms of migration overhead. It really doesn't make sense to generally optimize for migration as that often translates directly to overhead in actual hot paths in various controllers. That said, I don't think it'd be too difficult to keep things acceptable for the android case. Thanks. -- tejun ^ permalink raw reply [flat|nested] 67+ messages in thread
end of thread, other threads:[~2016-07-14 19:35 UTC | newest] Thread overview: 67+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-07-13 0:00 Severe performance regression w/ 4.4+ on Android due to cgroup locking changes John Stultz 2016-07-13 8:21 ` Peter Zijlstra 2016-07-13 14:42 ` Paul E. McKenney 2016-07-13 18:13 ` Dmitry Shmidt 2016-07-13 18:32 ` Paul E. McKenney 2016-07-13 18:21 ` Tejun Heo 2016-07-13 18:33 ` Tejun Heo 2016-07-13 20:13 ` John Stultz 2016-07-13 20:18 ` Tejun Heo 2016-07-13 20:26 ` Peter Zijlstra 2016-07-13 20:39 ` Tejun Heo 2016-07-13 20:51 ` Peter Zijlstra 2016-07-13 21:01 ` Tejun Heo 2016-07-13 21:03 ` Paul E. McKenney 2016-07-13 21:05 ` Tejun Heo 2016-07-13 21:18 ` Paul E. McKenney 2016-07-13 21:42 ` Paul E. McKenney 2016-07-13 21:46 ` John Stultz 2016-07-13 22:17 ` Paul E. McKenney 2016-07-13 22:39 ` John Stultz 2016-07-13 23:02 ` Paul E. McKenney 2016-07-13 23:04 ` Paul E. McKenney 2016-07-14 11:35 ` Tejun Heo 2016-07-14 12:04 ` Peter Zijlstra 2016-07-14 12:08 ` Tejun Heo 2016-07-14 12:20 ` Peter Zijlstra 2016-07-14 15:07 ` Tejun Heo 2016-07-14 15:24 ` Tejun Heo 2016-07-14 16:32 ` Peter Zijlstra 2016-07-14 17:34 ` Oleg Nesterov 2016-07-14 16:54 ` John Stultz 2016-07-13 22:25 ` John Stultz 2016-07-13 22:01 ` Tejun Heo 2016-07-13 22:33 ` Paul E. McKenney 2016-07-14 6:49 ` Peter Zijlstra 2016-07-14 11:20 ` Tejun Heo 2016-07-14 12:11 ` Peter Zijlstra 2016-07-14 15:14 ` Tejun Heo 2016-07-14 13:18 ` Peter Zijlstra 2016-07-14 14:14 ` Peter Zijlstra 2016-07-14 14:58 ` Oleg Nesterov 2016-07-14 16:14 ` Peter Zijlstra 2016-07-14 16:37 ` Peter Zijlstra 2016-07-14 17:05 ` Oleg Nesterov 2016-07-14 16:23 ` Paul E. McKenney 2016-07-14 16:45 ` Peter Zijlstra 2016-07-14 17:15 ` Paul E. McKenney 2016-07-14 16:43 ` John Stultz 2016-07-14 16:49 ` Peter Zijlstra 2016-07-14 17:02 ` John Stultz 2016-07-14 17:13 ` Oleg Nesterov 2016-07-14 17:30 ` John Stultz 2016-07-14 17:41 ` Oleg Nesterov 2016-07-14 17:51 ` John Stultz 2016-07-14 18:09 ` Oleg Nesterov 2016-07-14 18:36 ` Peter Zijlstra 2016-07-14 19:35 ` Peter Zijlstra 2016-07-13 20:57 ` John Stultz 2016-07-13 20:52 ` Paul E. McKenney 2016-07-13 20:57 ` Peter Zijlstra 2016-07-13 21:08 ` Paul E. McKenney 2016-07-13 21:01 ` Dmitry Shmidt 2016-07-13 21:03 ` John Stultz 2016-07-13 21:05 ` Paul E. McKenney 2016-07-13 20:31 ` Dmitry Shmidt 2016-07-13 20:44 ` Colin Cross 2016-07-13 20:54 ` Tejun Heo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).