do_shrink_slab() scans each shrinker in batches of at most
batch_size (128) pages at a time until total_scan pages are
scanned or until shrinker returns SHRINK_STOP. Under heavy
memory pressure total_scan can be large (in thousands) and
kgsl_pool_shrink_scan_objects() ends up returning 0 after
all pages that were reclaimable are reclaimed. This results in
multiple calls to kgsl_pool_shrink_scan_objects() that do not
reclaim any memory. To prevent this kgsl_pool_shrink_scan_objects()
is modified to return SHRINK_STOP as soon as no more memory can
be reclaimed.
Bug: 69931996
Test: tested using alloc-stress with additional traces
Change-Id: Ia48fc2c0d888c54ec9642c0b0962a70ca3cb4c5e
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Adam W. Willis <return.of.octobot@gmail.com>
LZ4 final literal copy could be overlapped when doing
in-place decompression, so it's unsafe to just use memcpy()
on an optimized memcpy approach but memmove() instead.
Upstream LZ4 has updated this years ago [1] (and the impact
is non-sensible [2] plus only a few bytes remain), this commit
just synchronizes LZ4 upstream code to the kernel side as well.
It can be observed as EROFS in-place decompression failure
on specific files when X86_FEATURE_ERMS is unsupported,
memcpy() optimization of commit 59daa706fbec ("x86, mem:
Optimize memcpy by avoiding memory false dependece") will
be enabled then.
Currently most modern x86-CPUs support ERMS, these CPUs just
use "rep movsb" approach so no problem at all. However, it can
still be verified with forcely disabling ERMS feature...
arch/x86/lib/memcpy_64.S:
ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \
- "jmp memcpy_erms", X86_FEATURE_ERMS
+ "jmp memcpy_orig", X86_FEATURE_ERMS
We didn't observe any strange on arm64/arm/x86 platform before
since most memcpy() would behave in an increasing address order
("copy upwards" [3]) and it's the correct order of in-place
decompression but it really needs an update to memmove() for sure
considering it's an undefined behavior according to the standard
and some unique optimization already exists in the kernel.
[1] 33cb8518ac
[2] https://github.com/lz4/lz4/pull/717#issuecomment-497818921
[3] https://sourceware.org/bugzilla/show_bug.cgi?id=12518
Link: https://lkml.kernel.org/r/20201122030749.2698994-1-hsiangkao@redhat.com
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
Reviewed-by: Nick Terrell <terrelln@fb.com>
Cc: Yann Collet <yann.collet.73@gmail.com>
Cc: Miao Xie <miaoxie@huawei.com>
Cc: Chao Yu <yuchao0@huawei.com>
Cc: Li Guifu <bluce.liguifu@huawei.com>
Cc: Guo Xuenan <guoxuenan@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Changes:
--------
v4->v3:
- s/random_stack_user()/get_atrandom_bytes()/
- Move this function to ahead of its use to avoid the predeclaration.
v3->v2:
- Tweak code comments of random_stack_user().
- Remove redundant bits mask and shift upon the random variable.
v2->v1:
- Fix random copy to check up buffer length that are not 4-byte multiples.
v3 can be found at:
http://www.spinics.net/lists/linux-fsdevel/msg59597.html
v2 can be found at:
http://www.spinics.net/lists/linux-fsdevel/msg59418.html
v1 can be found at:
http://www.spinics.net/lists/linux-fsdevel/msg59128.html
Thanks,
-Jeff
Entropy is quickly depleted under normal operations like ls(1), cat(1),
etc... between 2.6.30 to current mainline, for instance:
$ cat /proc/sys/kernel/random/entropy_avail
3428
$ cat /proc/sys/kernel/random/entropy_avail
2911
$cat /proc/sys/kernel/random/entropy_avail
2620
We observed this problem has been occurring since 2.6.30 with
fs/binfmt_elf.c: create_elf_tables()->get_random_bytes(), introduced by
f06295b44c296c8f ("ELF: implement AT_RANDOM for glibc PRNG seeding").
/*
* Generate 16 random bytes for userspace PRNG seeding.
*/
get_random_bytes(k_rand_bytes, sizeof(k_rand_bytes));
The patch introduces a wrapper around get_random_int() which has lower
overhead than calling get_random_bytes() directly.
With this patch applied:
$ cat /proc/sys/kernel/random/entropy_avail
2731
$ cat /proc/sys/kernel/random/entropy_avail
2802
$ cat /proc/sys/kernel/random/entropy_avail
2878
Analyzed by John Sobecki.
Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <aedilger@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Arnd Bergmann <arnn@arndb.de>
Cc: John Sobecki <john.sobecki@oracle.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Ted Ts'o <tytso@mit.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Ulrich Drepper <drepper@redhat.com>
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
This silences the following compilation warning, presumably emitted
by llvm-ar in conjunction with Clang (Thin)LTO:
lib/nmi_backtrace.o: no symbols
This is a watchdog support library which is no-op on this
architecture, hence the empty object file, so let's avoid building
it entirely until a more aesthetically pleasing solution presents
itself.
Signed-off-by: Adam W. Willis <return.of.octobot@gmail.com>
Co-authored-by: Panchajanya1999 <panchajanya@azure-dev.live>
Subsequent to c251c5f ("Makefile: Use O3 for Clang")
Ensure vDSO uses the same optimization level as the rest of the
kernel, which is O3, when compiling with Clang.
Signed-off-by: Adam W. Willis <return.of.octobot@gmail.com>
Signed-off-by: Adithya R <gh0strider.2k18.reborn@gmail.com>
Currently, ktime_us_delta() is invoked unconditionally to compute the
idle residency of the CPU, but it only makes sense to do that if a
valid idle state has been entered, so move the ktime_us_delta()
invocation after the entered_state >= 0 check.
While at it, merge two comment blocks in there into one and drop
a space between type casting of diff.
This patch has no functional changes.
Signed-off-by: Fieah Lim <kw@fieahl.im>
[ rjw: Changelog cleanup, comment format fix ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Adam W. Willis <return.of.octobot@gmail.com>
It was negating the user set max cpu freq and boosting over it if for example input_boost_freq > max_freq, so fix it
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
This change is for general scheduler improvements.
Change-Id: I4623a59eca688209110c347d388df2a2839a6287
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Just like the ttwu_queue_remote() IPI, make use of _TIF_POLLING_NRFLAG
to avoid sending IPIs to idle CPUs.
[ mingo: Fix UP build bug. ]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200526161907.953304789@infradead.org
Signed-off-by: Vishalcj17 <vishalcj@aospa.co>
Change-Id: Ife9ead8594aec91756d40381cc0fff1d187ebded
This should make the kernel initialization faster as it suppresses any
potential serial console output.
Change-Id: Iafcb84908f0911f14b0c560c2122d9be65bf216f
Signed-off-by: Adithya R <gh0strider.2k18.reborn@gmail.com>
Because of less NAPI budget it's need to reschedule multiple
times in high tput scenario.To avoid multiple reschedule
configuring maximum NAPI budget value.
Change-Id: Id8745b54c3909d01df69376a823396ea4c94eebb
Signed-off-by: Ashok Vuyyuru <avuyyuru@codeaurora.org>
Signed-off-by: celtare21 <celtare21@gmail.com>
Observed race between timeout fault (long IB detection) and
MISC hang (hard fault). MISC hang can be set while in recovery from
timeout fault. If fault flag is set in start path CP init fails.
Clear gpu fault to avoid such race.
Change-Id: Id99dcefd0ef3438bc95c6c3c84e2eadce214cf77
Signed-off-by: Pranav Patel <pranavp@codeaurora.org>
Signed-off-by: celtare21 <celtare21@gmail.com>
When kernel panic, irqs will be disabled, dma_free_attrs is
called frequently when dump wlan firmware, too much printk by
WARN_ON(irqs_disabled()) make watchdog bite
Change-Id: I9bf18d73c1468c8829bce77898849b3eef07271f
Signed-off-by: Jianmin Zhu <jianminz@codeaurora.org>
Signed-off-by: celtare21 <celtare21@gmail.com>
BFQ is already doing a similar thing in its .pd_offline_fn() method
implementation.
While it seems that after commit 4c6994806f70
("blk-throttle: fix race between blkcg_bio_issue_check() and cgroup_rmdir()")
was reverted leaving these pointers intact no longer causes crashes
clearing them is still a sensible thing to do to make the code more robust.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: celtare21 <celtare21@gmail.com>
cfq and bfq have some internal fields that use sched_clock() which can
trivially use ktime_get_ns() instead. Their timestamp fields in struct
request can also use ktime_get_ns(), which resolves the 8 year old
comment added by commit 28f4197e5d47 ("block: disable preemption before
using sched_clock()").
Signed-off-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: celtare21 <celtare21@gmail.com>
This patch enables tail loss probe in cwnd reduction (CWR) state
to detect potential losses. Prior to this patch, since the sender
uses PRR to determine the cwnd in CWR state, the combination of
CWR+PRR plus tcp_tso_should_defer() could cause unnecessary stalls
upon losses: PRR makes cwnd so gentle that tcp_tso_should_defer()
defers sending wait for more ACKs. The ACKs may not come due to
packet losses.
Disallowing TLP when there is unused cwnd had the primary effect
of disallowing TLP when there is TSO deferral, Nagle deferral,
or we hit the rwin limit. Because basically every application
write() or incoming ACK will cause us to run tcp_write_xmit()
to see if we can send more, and then if we sent something we call
tcp_schedule_loss_probe() to see if we should schedule a TLP. At
that point, there are a few common reasons why some cwnd budget
could still be unused:
(a) rwin limit
(b) nagle check
(c) TSO deferral
(d) TSQ
For (d), after the next packet tx completion the TSQ mechanism
will allow us to send more packets, so we don't really need a
TLP (in practice it shouldn't matter whether we schedule one
or not). But for (a), (b), (c) the sender won't send any more
packets until it gets another ACK. But if the whole flight was
lost, or all the ACKs were lost, then we won't get any more ACKs,
and ideally we should schedule and send a TLP to get more feedback.
In particular for a long time we have wanted some kind of timer for
TSO deferral, and at least this would give us some kind of timer
Reported-by: Steve Ibanez <sibanez@stanford.edu>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Reviewed-by: Nandita Dukkipati <nanditad@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Signed-off-by: celtare21 <celtare21@gmail.com>
f2fs already addresses gc_urgent under discard, but still uses the
default wait_ms.
To gain as many free segments as fast as possible,
use 1 for wait_ms under gc_urgent for discards.
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Signed-off-by: celtare21 <celtare21@gmail.com>
Waking up discard thread on 50ms interval is way too aggressive,
even when the user has only 20% of space left.
60000ms vs 50ms is too much of a stark difference.
Use 10 seconds instead.
The use of Rapid GC also makes this switch more reasonable.
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Signed-off-by: celtare21 <celtare21@gmail.com>
GC itself will produce some dirty segments.
This will allow more GCs to be made upon rapid GC or urgent GC.
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Signed-off-by: celtare21 <celtare21@gmail.com>
The transaction logging (and especially strcmp call) is unnecessary for
us and adds measurably significant overhead. Kill it entirely.
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Signed-off-by: celtare21 <celtare21@gmail.com>
The loop in alarm_cancel() is similar to the ones in the
timer drivers as it disables IRQs as well.
So we need to add an ndelay() call after the cpu_relax() call
to avoid potential scheduling delays due to IRQ stalling.
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Calling usleep_range with identical min and max values,
results in a delta of 0us.
This causes the issue that the scheduler gets no chance to re-use an already
scheduled interrupt for this wait which results in a negative performance
impact by adding uninterruptible sleep.
Fix the issue by allowing the delay to take 20% longer than requested.
This should be good enough for these cases.
Signed-off-by: Alex Naidis <alex.naidis@paranoidandroid.co>
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
echo 0 /sys/kernel/fast_charge/force_fast_charge (disable)
echo 1 /sys/kernel/fast_charge/force_fast_charge (enable)
Enables force charging up to 900mA in usb2 mode
Signed-off-by: engstk <eng.stk@sapo.pt>
CAF's new fuel gauge drivers report POWER_SUPPLY_TYPE_BMS (Battery
Monitor System) instead of POWER_SUPPLY_TYPE_BATTERY (battery), and
rightfully so because it describes their purpose more accurately.
Update the power_supply_is_system_supplied function to recognize BMS
power supplies as batteries to prevent it from attempting to query the
POWER_SUPPLY_PROP_ONLINE property on our fuel gauge drivers.
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Potential concurrent accesses to vote_clock_on/off() functions
may leave runtime PM in an unwanted state.
Change-Id: Ie317e8b191f5ab4083071ea55210006fb06f8079
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Signed-off-by: celtare21 <celtare21@gmail.com>
Signed-off-by: Yaroslav Furman <yaro330@gmail.com>
Signed-off-by: Adithya R <gh0strider.2k18.reborn@gmail.com>
Average userspace response time from ISR is less than 10ms.
Whooping 2 seconds is way too long. Reduce it to 100ms.
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Change-Id: I78e1f434f6e5585497972ee82b2a29c5cfd87408
Signed-off-by: Yaroslav Furman <yaro330@gmail.com>
Bug: 142000171
cherry-pick from I81666dcc18c584dbcbd9f588f187ae87a377bcb0
Signed-off-by: Jie Song <jies@google.com>
Change-Id: I7bb84dec4d352ef731b2457dc15590a29ed57a90
Signed-off-by: Adam W. Willis <return.of.octobot@gmail.com>
Signed-off-by: UtsavisGreat <utsavbalar1231@gmail.com>
Signed-off-by: Yaroslav Furman <yaro330@gmail.com>
These can get stuck sometimes and prevert system from sleeping.
Signed-off-by: Yaroslav Furman <yaro330@gmail.com>
Signed-off-by: alk3pInjection <webmaster@raspii.tech>
(cherry picked from commit cd8489c06a3de8c70c6236f91290dd72f46023f4)
Android devices use LMK algorythms, so there's no
reason to disable and enable the OOM killer when entering and exiting
suspend.
This is a fixed version of https://github.com/YaroST12/VIOLENT_kernel/commit/86e59a93b2ef
Co-authored-by: Danny Lin <danny@kdrag0n.dev>
Signed-off-by: Yaroslav Furman <yaro330@gmail.com>
Signed-off-by: alk3pInjection <webmaster@raspii.tech>
These debug logs are everywhere and not only bloat the driver, but add
latency everywhere they're used because they're not compiled out. Since
they serve no purpose for us as we're not debugging SDE, compile them
out.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Signed-off-by: Yaroslav Furman <yaro330@gmail.com>
