zs_stat_inc/dec/get() uses enum zs_stat_type for the stat type, however
some callers pass an enum fullness_group value. Change the type to int to
reflect the actual use of the functions and get rid of 'enum-conversion'
warnings
Link: http://lkml.kernel.org/r/20170731175000.56538-1-mka@chromium.org
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Doug Anderson <dianders@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 3eb95feac113d8ebad5b7b5189a65efcbd95a749)
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Account for extra IRQ load from such events like display rendering, touch events, etc...
that needs bandwidth raise for optimal performance
Signed-off-by: Diep Quynh <remilia.1505@gmail.com>
Signed-off-by: SamarV-121 <samarvispute121@gmail.com>
Using debuggers on clock scaling unit causes performance degradation
on production units. Let's disable it from now
Signed-off-by: Diep Quynh <remilia.1505@gmail.com>
Signed-off-by: SamarV-121 <samarvispute121@gmail.com>
On devices with a CPU that contains heterogeneous cores (e.g.,
big.LITTLE), it can be beneficial to place some performance-critical
IRQs and kthreads onto the performance CPU cluster in order to improve
performance.
This commit adds the following APIs:
-kthread_run_perf_critical() to create and start a perf-critical kthread
-irq_set_perf_affinity() to mark an active IRQ as perf-critical
-IRQF_PERF_CRITICAL to schedule an IRQ and any threads it may have onto
performance CPUs
-PF_PERF_CRITICAL to mark a process (mainly a kthread) as performance
critical (this is used by kthread_run_perf_critical())
In order to accommodate this new API, the following changes are made:
-Performance-critical IRQs are distributed evenly among online CPUs
available in cpu_perf_mask
-Performance-critical IRQs have their affinities reaffined upon exit
from suspend (since the affinities are broken when non-boot CPUs are
disabled)
-Performance-critical IRQs and their threads have their affinities reset
upon entering suspend, so that upon immediate suspend exit (when only
the boot CPU is online), interrupts can be processed and interrupt
threads can be scheduled onto an online CPU (otherwise we'd hit a
kernel BUG)
-__set_cpus_allowed_ptr() is modified to enforce a performance-critical
kthread's affinity
-Perf-critical IRQs are marked with IRQD_AFFINITY_MANAGED so userspace
can't mess with their affinity
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Add cpu_lp_mask and cpu_perf_mask to represent the CPUs that belong to
each cluster in a dual-cluster, heterogeneous system.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Signed-off-by: SamarV-121 <samarvispute121@gmail.com>
Add IRQ_AFFINITY_MANAGED flag and related kernel APIs so that
kernel driver can modify an irq's status in such a way that
user space affinity change will be ignored. Kernel space's
affinity setting will not be changed.
Change-Id: Ib2d5ea651263bff4317562af69079ad950c9e71e
Signed-off-by: Runmin Wang <runminw@codeaurora.org>
Interupts marked with this flag are excluded from user space interrupt
affinity changes. Contrary to the IRQ_NO_BALANCING flag, the kernel internal
affinity mechanism is not blocked.
This flag will be used for multi-queue device interrupts.
Change-Id: I204c49bb1c8ce87fbcd163119093163b120bfe83
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: linux-block@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: linux-nvme@lists.infradead.org
Cc: axboe@fb.com
Cc: agordeev@redhat.com
Link: http://lkml.kernel.org/r/1467621574-8277-3-git-send-email-hch@lst.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Git-commit: 9c2555835bb3d34dfac52a0be943dcc4bedd650f
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[runminw@codeaurora.org: resolve trivial merge conflicts]
Signed-off-by: Runmin Wang <runminw@codeaurora.org>
There are now two lists:
- the previously existing list of user defined wakelocks to block
- a new list called "wakelock_blocker_default" which comes prepopulated with the most common
and safe wakelocks to block:
qcom_rx_wakelock;wlan;wlan_wow_wl;wlan_extscan_wl;netmgr_wl;NETLINK
A combination of both wakelock lists will be blocked finally.
Signed-off-by: djb77 <dwayne.bakewell@gmail.com>
Based on ideas of FranciscoFranco's non-generic driver.
Sysfs node:
/sys/class/misc/boeffla_wakelock_blocker/wakelock_blocker
- list of wakelocks to be blocked, separated by semicolons
/sys/class/misc/boeffla_wakelock_blocker/debug
- write: 0/1 to switch off and on debug logging into dmesg
- read: get current driver internals
/sys/class/misc/boeffla_wakelock_blocker/version
- show driver version
Signed-off-by: andip71 <andreasp@gmx.de>
Signed-off-by: djb77 <dwayne.bakewell@gmail.com>
Currently, CPU can enter deep sleep while waiting for data on the i2c
bug. That means an i2c read of 8 bytes can take as long as 10 ms, which
would overrun the desired interrupt handling time.
Use pm qos to require low latency and prevent CPU from entering deep
sleep while handling touch interrupts.
Bug: 110939384
Test: look at the i2c read traces:
1) ./external/chromium-trace/systrace.py --atrace-categories=view,wm,am,app,gfx,i2c,sched,irq,video,power,input,workq,freq
2) perform a fling
3) review the i2c read duration on the touchscreen bus
Change-Id: Icf8ab09324003a85af70517769ced3bae52f705c
Signed-Off-By: Siarhei Vishniakou <svv@google.com>
