Patch series "mm: lru related cleanups", v2.
The cleanups are intended to reduce the verbosity in lru list operations
and make them less error-prone. A typical example would be how the
patches change __activate_page():
static void __activate_page(struct page *page, struct lruvec *lruvec)
{
if (!PageActive(page) && !PageUnevictable(page)) {
- int lru = page_lru_base_type(page);
int nr_pages = thp_nr_pages(page);
- del_page_from_lru_list(page, lruvec, lru);
+ del_page_from_lru_list(page, lruvec);
SetPageActive(page);
- lru += LRU_ACTIVE;
- add_page_to_lru_list(page, lruvec, lru);
+ add_page_to_lru_list(page, lruvec);
trace_mm_lru_activate(page);
There are a few more places like __activate_page() and they are
unnecessarily repetitive in terms of figuring out which list a page should
be added onto or deleted from. And with the duplicated code removed, they
are easier to read, IMO.
Patch 1 to 5 basically cover the above. Patch 6 and 7 make code more
robust by improving bug reporting. Patch 8, 9 and 10 take care of some
dangling helpers left in header files.
This patch (of 10):
There is add_page_to_lru_list(), and move_pages_to_lru() should reuse it,
not duplicate it.
Link: https://lkml.kernel.org/r/20210122220600.906146-1-yuzhao@google.com
Link: https://lore.kernel.org/linux-mm/20201207220949.830352-2-yuzhao@google.com/
Link: https://lkml.kernel.org/r/20210122220600.906146-2-yuzhao@google.com
Signed-off-by: Yu Zhao <yuzhao@google.com>
Reviewed-by: Alex Shi <alex.shi@linux.alibaba.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Roman Gushchin <guro@fb.com>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 42895ea73bcd37c4a79e4c9f681ab8b82243c7f7)
BUG=b:123039911
TEST=Built
Change-Id: I11a7493ee7263b03453c2bc203e9770e12f2577a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2914041
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Yu Zhao <yuzhao@chromium.org>
Tested-by: Yu Zhao <yuzhao@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
To activate a page, mark_page_accessed() always holds a reference on it.
It either gets a new reference when adding a page to
lru_pvecs.activate_page or reuses an existing one it previously got when
it added a page to lru_pvecs.lru_add. So it doesn't call SetPageActive()
on a page that doesn't have any reference left. Therefore, the race is
impossible these days (I didn't brother to dig into its history).
For other paths, namely reclaim and migration, a reference count is always
held while calling SetPageActive() on a page.
SetPageSlabPfmemalloc() also uses SetPageActive(), but it's irrelevant to
LRU pages.
Signed-off-by: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Yang Shi <shy828301@gmail.com>
Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Qian Cai <cai@lca.pw>
Link: http://lkml.kernel.org/r/20200818184704.3625199-2-yuzhao@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 6f4dd8de4835563de9bae797ce1d7a13465a7a7d)
BUG=b:123039911
TEST=Built
Change-Id: I3e50ae28408b2936b1eb72210b3046eac8485701
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2914039
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Yu Zhao <yuzhao@chromium.org>
Tested-by: Yu Zhao <yuzhao@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
This is a cleanup patch that replaces two historical uses of
list_move_tail() with relatively recent add_page_to_lru_list_tail().
Link: http://lkml.kernel.org/r/20190716212436.7137-1-yuzhao@google.com
Signed-off-by: Yu Zhao <yuzhao@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit e7a1aaf28770c1f7a06c50cbd02ca0f27ce61ec5)
BUG=b:123039911
TEST=Built
Change-Id: I69db770430d1d282927c31ee8a352532901c774d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2914037
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Yu Zhao <yuzhao@chromium.org>
Tested-by: Yu Zhao <yuzhao@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Exclude min_filelist_kbytes from zone_reclaimable_pages to protect file
cache. Without this patch, sometimes the file cache drops below 10 MBs
and system freezes. This feature is on ChromeOS kernel 4.4 and older.
BUG=chromium:1049480
TEST=run platform.MemoryStressBasic
Signed-off-by: Kuo-Hsin Yang <vovoy@chromium.org>
Change-Id: Idc0ff68714d159188e740a5bc98ceeccddd46af9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2040972
Reviewed-by: Yu Zhao <yuzhao@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
If we are already under list_lock, don't call kmalloc(). Otherwise we
will run into deadlock because kmalloc() also tries to grab the same
lock.
Fixing the problem by using a static bitmap instead.
WARNING: possible recursive locking detected
--------------------------------------------
mount-encrypted/4921 is trying to acquire lock:
(&(&n->list_lock)->rlock){-.-.}, at: ___slab_alloc+0x104/0x437
but task is already holding lock:
(&(&n->list_lock)->rlock){-.-.}, at: __kmem_cache_shutdown+0x81/0x3cb
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&n->list_lock)->rlock);
lock(&(&n->list_lock)->rlock);
*** DEADLOCK ***
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Yu Zhao <yuzhao@google.com>
(am from https://patchwork.kernel.org/patch/11235437/)
BUG=chromium:1002274
TEST=built
Change-Id: I86741ccc2842e5657c77edd67a73b40bcdc40f14
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1907471
Tested-by: Yu Zhao <yuzhao@chromium.org>
Auto-Submit: Yu Zhao <yuzhao@chromium.org>
Reviewed-by: Salman Qazi <sqazi@google.com>
Commit-Queue: Yu Zhao <yuzhao@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
The function doesn't need to return any value, and the check can be
done in one pass.
There is a behavior change: before the patch, we stop at the first
invalid free object; after the patch, we stop at the first invalid
object, free or in use. This shouldn't matter because the original
behavior isn't intended anyway.
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Yu Zhao <yuzhao@google.com>
(am from https://patchwork.kernel.org/patch/11235435/)
BUG=chromium:1002274
TEST=built
Change-Id: Id441417e5cb4ef70e5cf9f1d2e2523c3198cb816
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1907470
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Salman Qazi <sqazi@google.com>
Tested-by: Yu Zhao <yuzhao@chromium.org>
Auto-Submit: Yu Zhao <yuzhao@chromium.org>
Commit-Queue: Yu Zhao <yuzhao@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
I got a report there is THP user with perproc reclaim. Thus, this patch
adds THP page handling logic. It's almost same with MADV_FREE in that
"let's do not split the THP page unless we are not sure because THP
collapsing is never cheap". To achieve it, it splits the page only if
we know there is only user for the page via page_mapcount check.
BUG=chromium:973963
TEST=build/boot/test on 4.19
Change-Id: Ia32eceb25742362033a9b365a39c06c40f3e735c
Signed-off-by: Minchan Kim <minchan@google.com>
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: Brian Geffon <bgeffon@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1894522
Reviewed-by: Yu Zhao <yuzhao@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
(cherry picked from commit 6e2df0581f569038719cf2bc2b3baa3fcc83cab4)
Commit 67692435c411 ("sched: Rework pick_next_task() slow-path")
inadvertly introduced a race because it changed a previously
unexplored dependency between dropping the rq->lock and
sched_class::put_prev_task().
The comments about dropping rq->lock, in for example
newidle_balance(), only mentions the task being current and ->on_cpu
being set. But when we look at the 'change' pattern (in for example
sched_setnuma()):
queued = task_on_rq_queued(p); /* p->on_rq == TASK_ON_RQ_QUEUED */
running = task_current(rq, p); /* rq->curr == p */
if (queued)
dequeue_task(...);
if (running)
put_prev_task(...);
/* change task properties */
if (queued)
enqueue_task(...);
if (running)
set_next_task(...);
It becomes obvious that if we do this after put_prev_task() has
already been called on @p, things go sideways. This is exactly what
the commit in question allows to happen when it does:
prev->sched_class->put_prev_task(rq, prev, rf);
if (!rq->nr_running)
newidle_balance(rq, rf);
The newidle_balance() call will drop rq->lock after we've called
put_prev_task() and that allows the above 'change' pattern to
interleave and mess up the state.
Furthermore, it turns out we lost the RT-pull when we put the last DL
task.
Fix both problems by extracting the balancing from put_prev_task() and
doing a multi-class balance() pass before put_prev_task().
BUG=b:152605392
TEST=run power_VideoCall test
Fixes: 67692435c411 ("sched: Rework pick_next_task() slow-path")
Reported-by: Quentin Perret <qperret@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Quentin Perret <qperret@google.com>
Tested-by: Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Joel Fernandes <joelaf@google.com>
Change-Id: Ia202a8c1890d2f38a27b1cf93f8f4d27e48d5220
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2187130
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
(cherry picked from commit 67692435c411e)
Avoid the RETRY_TASK case in the pick_next_task() slow path.
By doing the put_prev_task() early, we get the rt/deadline pull done,
and by testing rq->nr_running we know if we need newidle_balance().
This then gives a stable state to pick a task from.
Since the fast-path is fair only; it means the other classes will
always have pick_next_task(.prev=NULL, .rf=NULL) and we can simplify.
BUG=b:152605392
TEST=run power_VideoCall test
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Aaron Lu <aaron.lwe@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: mingo@kernel.org
Cc: Phil Auld <pauld@redhat.com>
Cc: Julien Desfossez <jdesfossez@digitalocean.com>
Cc: Nishanth Aravamudan <naravamudan@digitalocean.com>
Link: https://lkml.kernel.org/r/aa34d24b36547139248f32a30138791ac6c02bd6.1559129225.git.vpillai@digitalocean.com
Signed-off-by: Joel Fernandes <joelaf@google.com>
Change-Id: I2029a0b9994aeddf83248bf5da67c93f2290f5e7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2186288
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
(cherry picked from commit 5ba553eff0c3a)
For pick_next_task_fair() it is the newidle balance that requires
dropping the rq->lock; provided we do put_prev_task() early, we can
also detect the condition for doing newidle early.
BUG=b:152605392
TEST=run power_VideoCall test
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Aaron Lu <aaron.lwe@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: mingo@kernel.org
Cc: Phil Auld <pauld@redhat.com>
Cc: Julien Desfossez <jdesfossez@digitalocean.com>
Cc: Nishanth Aravamudan <naravamudan@digitalocean.com>
Link: https://lkml.kernel.org/r/9e3eb1859b946f03d7e500453a885725b68957ba.1559129225.git.vpillai@digitalocean.com
Signed-off-by: Joel Fernandes <joelaf@google.com>
Change-Id: I7668fc1a0f04219846e1b78d899aa6d06780aecc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2186287
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
(cherry picked from commit 5f2a45fc9e89e)
Currently the pick_next_task() loop is convoluted and ugly because of
how it can drop the rq->lock and needs to restart the picking.
For the RT/Deadline classes, it is put_prev_task() where we do
balancing, and we could do this before the picking loop. Make this
possible.
BUG=b:152605392
TEST=run power_VideoCall test
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Aaron Lu <aaron.lwe@gmail.com>
Cc: mingo@kernel.org
Cc: Phil Auld <pauld@redhat.com>
Cc: Julien Desfossez <jdesfossez@digitalocean.com>
Cc: Nishanth Aravamudan <naravamudan@digitalocean.com>
Link: https://lkml.kernel.org/r/e4519f6850477ab7f3d257062796e6425ee4ba7c.1559129225.git.vpillai@digitalocean.com
Signed-off-by: Joel Fernandes <joelaf@google.com>
Change-Id: Idf5d6f6565f72af554173e907c94ad9819266c2c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2186286
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
(cherry picked from commit 10e7071b2f491)
The CPU hotplug task selection is the only place where we used
put_prev_task() on a task that is not current. While looking at that,
it occured to me that we can simplify all that by by using a custom
pick loop.
Since we don't need to put current, we can do away with the fake task
too.
BUG=b:152605392
TEST=run power_VideoCall test
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Aaron Lu <aaron.lwe@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: mingo@kernel.org
Cc: Phil Auld <pauld@redhat.com>
Cc: Julien Desfossez <jdesfossez@digitalocean.com>
Cc: Nishanth Aravamudan <naravamudan@digitalocean.com>
Signed-off-by: Joel Fernandes <joelaf@google.com>
Change-Id: I75315b91d18d47464519cbccc89c070af08773c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2186285
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
(cherry picked from commit 03b7fad167efc)
In preparation of further separating pick_next_task() and
set_curr_task() we have to pass the actual task into it, while there,
rename the thing to better pair with put_prev_task().
BUG=b:152605392
TEST=run power_VideoCall test
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Aaron Lu <aaron.lwe@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: mingo@kernel.org
Cc: Phil Auld <pauld@redhat.com>
Cc: Julien Desfossez <jdesfossez@digitalocean.com>
Cc: Nishanth Aravamudan <naravamudan@digitalocean.com>
Link: https://lkml.kernel.org/r/a96d1bcdd716db4a4c5da2fece647a1456c0ed78.1559129225.git.vpillai@digitalocean.com
Signed-off-by: Joel Fernandes <joelaf@google.com>
Change-Id: Ic4cdd6e6d0863b6cc5c626cb6ad9c5b81f86aff9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2186284
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
(cherry picked from commit f95d4eaee6d02)
Because pick_next_task() implies set_curr_task() and some of the
details haven't mattered too much, some of what _should_ be in
set_curr_task() ended up in pick_next_task, correct this.
This prepares the way for a pick_next_task() variant that does not
affect the current state; allowing remote picking.
BUG=b:152605392
TEST=run power_VideoCall test
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Aaron Lu <aaron.lwe@gmail.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: mingo@kernel.org
Cc: Phil Auld <pauld@redhat.com>
Cc: Julien Desfossez <jdesfossez@digitalocean.com>
Cc: Nishanth Aravamudan <naravamudan@digitalocean.com>
Link: https://lkml.kernel.org/r/38c61d5240553e043c27c5e00b9dd0d184dd6081.1559129225.git.vpillai@digitalocean.com
Signed-off-by: Joel Fernandes <joelaf@google.com>
Change-Id: Icdbb5f2dcb3ff7ca79590a541b94388804e6a1dd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2186283
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
(cherry picked from commit a68d75081aecc)
Commit:
f4ebcbc0d7 ("sched/rt: Substract number of tasks of throttled queues from rq->nr_running")
added a new rt_rq->rt_queued field, which is used to indicate the status of
rq->rt enqueue or dequeue. So, the ->rt_nr_running check was removed and we
now check ->rt_queued instead.
Fix the comment in pick_next_task_rt() as well, which was still referencing
the old logic.
BUG=b:152605392
TEST=run power_VideoCall test
Signed-off-by: Muchun Song <smuchun@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20181027030517.23292-1-smuchun@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Joel Fernandes <joelaf@google.com>
Change-Id: I1807b4c237d1c5eebcea8e3fe80f48b67bc0e672
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2186282
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
The current active_mm reference counting is confusing and sub-optimal.
Rewrite the code to explicitly consider the 4 separate cases:
user -> user
When switching between two user tasks, all we need to consider
is switch_mm().
user -> kernel
When switching from a user task to a kernel task (which
doesn't have an associated mm) we retain the last mm in our
active_mm. Increment a reference count on active_mm.
kernel -> kernel
When switching between kernel threads, all we need to do is
pass along the active_mm reference.
kernel -> user
When switching between a kernel and user task, we must switch
from the last active_mm to the next mm, hoping of course that
these are the same. Decrement a reference on the active_mm.
The code keeps a different order, because as you'll note, both 'to
user' cases require switch_mm().
And where the old code would increment/decrement for the 'kernel ->
kernel' case, the new code observes this is a neutral operation and
avoids touching the reference count.
BUG=b:152605392
TEST=run power_VideoCall test
(cherry picked from commit 139d025cda1da)
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Rik van Riel <riel@surriel.com>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: luto@kernel.org
Signed-off-by: Joel Fernandes <joelaf@google.com>
Change-Id: I9f26b68346c6d0eccf5b9c900c8b4d8dae4d4d42
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2186279
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
WARN_ON() already contains an unlikely(), so it's not necessary to
use WARN_ON(1).
BUG=b:152605392
TEST=run power_VideoCall test
(cherry picked from commit 9ebc6053814d3)
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20181103172602.1917-1-tiny.windzz@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Joel Fernandes <joelaf@google.com>
Change-Id: I1b1dc2bfbe6e07499cad3489fb193c0288e513ce
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2186278
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
When we pick the next task, we will do the following for the task:
1) p->se.exec_start = rq_clock_task(rq);
2) dequeue_pushable(_dl)_task(rq, p);
When we call set_curr_task(), we also need to do the same thing
above. In rt.c, the code at 1) is in the _pick_next_task_rt()
and the code at 2) is in the pick_next_task_rt(). If we put two
operations in one function, maybe better. So, we introduce a new
function set_next_task(), which is responsible for doing the above.
By introducing the function we can get rid of calling the
dequeue_pushable(_dl)_task() directly(We can call set_next_task())
in pick_next_task() and have better code readability and reuse.
In set_curr_task_rt(), we also can call set_next_task().
Do this things such that we end up with:
static struct task_struct *pick_next_task(struct rq *rq,
struct task_struct *prev,
struct rq_flags *rf)
{
/* do something else ... */
put_prev_task(rq, prev);
/* pick next task p */
set_next_task(rq, p);
/* do something else ... */
}
put_prev_task() can match set_next_task(), which can make the
code more readable.
BUG=b:152605392
TEST=run power_VideoCall test
(cherry picked from commit ff1cdc94de4d3)
Signed-off-by: Muchun Song <smuchun@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20181026131743.21786-1-smuchun@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Joel Fernandes <joelaf@google.com>
Change-Id: Ic02e2d2c792824bb57f5536ef38d5ca5d191b765
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2186277
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
In case of restore path there could be a chance that smp2p entry
duble freed or valid entry might be uninitialized. Also fix entry
deference after being freed by calling kfree().
Change-Id: I5dcb12e01972e19f3c0fa1fc1be3596abca984e9
Signed-off-by: Arun Prakash <app@codeaurora.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Add support in smp2p driver for suspend to disk feature.
Handling SMEM enumeration during resume from hibernation.
Change-Id: I5dd17057cc68a293a1a510ebedafc93defd8c556
Signed-off-by: Arun Prakash <app@codeaurora.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
There is a very tight race where the irq_retrigger function is run
on one cpu and the actual retrigger softirq is running on a second
cpu. When this happens, there may be a chance that the second cpu
will not see the updated irq_pending value from first cpu.
Add a memory barrier to ensure that irq_pending is read correctly.
Change-Id: I3dd185decc4f050bd57c0b6558f417ead2a3aa5a
Signed-off-by: Chris Lew <clew@codeaurora.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Move log statement so unchanged entries are logged. This increases log
spam to the ipc logging buffer but helps catch issues where a smp2p
interrupt is missed.
Change-Id: I695c324deec13b7a82b4838a1fc91fef594f7f8b
Signed-off-by: Chris Lew <clew@codeaurora.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
The ipc_log_string() function quietly checks for a NULL context so an
explicit check is not needed.
Change-Id: Ic0dedbada086a4daf011875cf3996c5749317307
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
If the task is pinned to a cpu, setting the misfit status means that
we'll unnecessarily continuously attempt to migrate the task but fail.
This continuous failure will cause the balance_interval to increase to
a high value, and eventually cause unnecessary significant delays in
balancing the system when real imbalance happens.
Caught while testing uclamp where rt-app calibration loop was pinned to
cpu 0, shortly after which we spawn another task with high util_clamp
value. The task was failing to migrate after over 40ms of runtime due to
balance_interval unnecessary expanded to a very high value from the
calibration loop.
Not done here, but it could be useful to extend the check for pinning to
verify that the affinity of the task has a cpu that fits. We could end
up in a similar situation otherwise.
Fixes: 3b1baa6496e6 ("sched/fair: Add 'group_misfit_task' load-balance type")
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Quentin Perret <qperret@google.com>
Acked-by: Valentin Schneider <valentin.schneider@arm.com>
Link: https://lkml.kernel.org/r/20210119120755.2425264-1-qais.yousef@arm.com
(cherry picked from commit 0ae78eec8aa64e645866e75005162603a77a0f49)
BUG=None (see commit c0d53bb091bb)
TEST=None
Signed-off-by: Linux Patches Robot <linux-patches-robot@chromeos-missing-patches.google.com.iam.gserviceaccount.com>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Change-Id: Ia6b8f829ce801df1b9caf4275b8ffba60c65ffc0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2719125
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Fix the "fuse: trying to steal weird page" warning.
Description from Johannes Weiner:
"Think of it as similar to PG_active. It's just another usage/heat
indicator of file and anon pages on the reclaim LRU that, unlike
PG_active, persists across deactivation and even reclaim (we store it in
the page cache / swapper cache tree until the page refaults).
So if fuse accepts pages that can legally have PG_active set,
PG_workingset is fine too."
Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Fixes: 1899ad18c607 ("mm: workingset: tell cache transitions from workingset thrashing")
Cc: <stable@vger.kernel.org> # v4.20
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
(cherry picked from commit b89ecd60d38ec042d63bdb376c722a16f92bcb88)
BUG=chromium:1028527
TEST=run the monitor example from PSI kernel documentation
Signed-off-by: Linux Patches Robot <linux-patches-robot@chromeos-missing-patches.google.com.iam.gserviceaccount.com>
Change-Id: I2148e47a1001afc5c7e6121eab34a40c4a7a96c4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3010306
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Yu Zhao <yuzhao@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Get channel number from ies is a common logic, so separate it to a new
function, which could also be used by lower driver.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Link: https://lore.kernel.org/r/20210930081533.4898-1-wgong@codeaurora.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit 97981d89a1d47942a2d7517631d2400b99fe3f93)
Conflicts:
include/net/cfg80211.h
net/wireless/scan.c
BUG=b:197916309
TEST=test case success: wifi.RRMBeaconReport
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Change-Id: I520f77730fcaeb4ab4ddd268ba6376cedaac0365
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3340327
Reviewed-by: Matthew Wang <matthewmwang@chromium.org>
Tested-by: Matthew Wang <matthewmwang@chromium.org>
Commit-Queue: Matthew Wang <matthewmwang@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Recently while investigating a problem with rr and signals I noticed
that siglock is dropped in ptrace_signal and get_signal does not jump
to relock.
Looking farther to see if the problem is anywhere else I see that
do_signal_stop also returns if signal_group_exit is true. I believe
that test can now never be true, but it is a bit hard to trace
through and be certain.
Testing signal_group_exit is not expensive, so move the test for
signal_group_exit into the for loop inside of get_signal to ensure
the test is never skipped improperly.
This has been a potential problem since I added the test for
signal_group_exit was added.
Fixes: 35634ffa1751 ("signal: Always notice exiting tasks")
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lkml.kernel.org/r/875yssekcd.fsf_-_@email.froward.int.ebiederm.org
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
(cherry picked from commit e7f7c99ba911f56bc338845c1cd72954ba591707)
BUG=None
TEST=None
Signed-off-by: Linux Patches Robot <linux-patches-robot@chromeos-missing-patches.google.com.iam.gserviceaccount.com>
Change-Id: Iec0140650d1ba8f1ac37964cf774a324ab73e490
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3396556
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Commit-Queue: Guenter Roeck <groeck@chromium.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
* After commit "Revert "dfc: Use alarm timer to trigger powersave work",
this workqueue is now is use for qmi_rmnet_check_stats. Make it unbound
and freezable to save power.
Signed-off-by: LibXZR <xzr467706992@163.com>
The tcp ancillary bit has been updated to be sent in almost all cases
unlike earlier where this was sent in case of TCP DL traffic.
This bit will now not be set only in case of adverse scenarios, so
this change ensures that the ACK queue state is updated in case the
ancillary bit is unset.
CRs-Fixed: 2957344
Change-Id: I4e1f26c9d3fabc64401284e36b48d82a4f3a5161
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Mike Kravetz reports that "hugetlb allocations could stall for minutes or
hours when should_compact_retry() would return true more often then it
should. Specifically, this was in the case where compact_result was
COMPACT_DEFERRED and COMPACT_PARTIAL_SKIPPED and no progress was being
made."
The problem is that the compaction_withdrawn() test in
should_compact_retry() includes compaction outcomes that are only possible
on low compaction priority, and results in a retry without increasing the
priority. This may result in furter reclaim, and more incomplete
compaction attempts.
With this patch, compaction priority is raised when possible, or
should_compact_retry() returns false.
The COMPACT_SKIPPED result doesn't really fit together with the other
outcomes in compaction_withdrawn(), as that's a result caused by
insufficient order-0 pages, not due to low compaction priority. With this
patch, it is moved to a new compaction_needs_reclaim() function, and for
that outcome we keep the current logic of retrying if it looks like
reclaim will be able to help.
Bug: 156785617
Link: http://lkml.kernel.org/r/20190806014744.15446-4-mike.kravetz@oracle.com
Reported-by: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Tested-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Hillf Danton <hdanton@sina.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I67134003597caa963d5ecff7e2a42ef101e3aa4a
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Right now the vmpressure window is of constant size 2MB, which
works well with the following exceptions.
1) False vmpressure triggers are seen when the RAM size is greater
than 3GB. This results in lowmemorykiller, which uses vmpressure
events, killing tasks unnecessarily.
2) Vmpressure events are received late under memory pressure. This
behaviour is seen prominently in <=2GB RAM targets. This results in
lowmemorykiller kicking in late to kill tasks resulting in avoidable
page cache reclaim.
The problem analysis shows that the issue is with the constant size
of the vmpressure window which does not adapt to the varying memory
conditions. This patch recalculates the vmpressure window size at
the end of each window. The chosen window size is proportional to
the total of free and cached memory at that point.
Change-Id: I7e9ef4ddd82e2c2dd04ce09ec8d58a8829cfb64d
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Currently, vmpressure is tied to memcg and its events are
available only to userspace clients. This patch removes
the dependency on CONFIG_MEMCG and adds a mechanism for
in-kernel clients to subscribe for vmpressure events (in
fact raw vmpressure values are delivered instead of vmpressure
levels, to provide clients more flexibility to take actions
on custom pressure levels which are not currently defined
by vmpressure module).
Change-Id: I38010f166546e8d7f12f5f355b5dbfd6ba04d587
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Fix an nr_isolate_* mismatch problem between cma and dirty lazyfree pages.
If try_to_unmap_one is used for reclaim and it detects a dirty lazyfree
page, then the lazyfree page is changed to a normal anon page having
SwapBacked by commit 802a3a92ad ("mm: reclaim MADV_FREE pages"). Even
with the change, reclaim context correctly counts isolated files because
it uses is_file_lru to distinguish file. And the change to anon is not
happened if try_to_unmap_one is used for migration. So migration context
like compaction also correctly counts isolated files even though it uses
page_is_file_lru insted of is_file_lru. Recently page_is_file_cache was
renamed to page_is_file_lru by commit 9de4f22a60f7 ("mm: code cleanup for
MADV_FREE").
But the nr_isolate_* mismatch problem happens on cma alloc. There is
reclaim_clean_pages_from_list which is being used only by cma. It was
introduced by commit 02c6de8d75 ("mm: cma: discard clean pages during
contiguous allocation instead of migration") to reclaim clean file pages
without migration. The cma alloc uses both reclaim_clean_pages_from_list
and migrate_pages, and it uses page_is_file_lru to count isolated files.
If there are dirty lazyfree pages allocated from cma memory region, the
pages are counted as isolated file at the beginging but are counted as
isolated anon after finished.
Mem-Info:
Node 0 active_anon:3045904kB inactive_anon:611448kB active_file:14892kB inactive_file:205636kB unevictable:10416kB isolated(anon):0kB isolated(file):37664kB mapped:630216kB dirty:384kB writeback:0kB shmem:42576kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
Like log above, there were too much isolated files, 37664kB, which
triggers too_many_isolated in reclaim even when there is no actually
isolated file in system wide. It could be reproducible by running two
programs, writing on MADV_FREE page and doing cma alloc, respectively.
Although isolated anon is 0, I found that the internal value of isolated
anon was the negative value of isolated file.
Fix this by compensating the isolated count for both LRU lists. Count
non-discarded lazyfree pages in shrink_page_list, then compensate the
counted number in reclaim_clean_pages_from_list.
Reported-by: Yong-Taek Lee <ytk.lee@samsung.com>
Suggested-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Shaohua Li <shli@fb.com>
Link: http://lkml.kernel.org/r/20200426011718.30246-1-jaewon31.kim@samsung.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Minchan Kim <minchan@google.com>
(cherry picked from commit 1f318a9b0dc3990490e98eef48f21e6f15185781)
Bug: 169151810
Change-Id: I549ab1a7210c97aaa92ca887ea3120c5ec085458
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Allow for vendor components or modules to override
"TLB conflict abort" handler,
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Test: Verified with scripts/gki/device_snapshot
Test: No impact on /sys/ (except new module files) and /dev/
Test: All devices probed as before
Bug: 141888626
Change-Id: I7d0a4d7440412f2ffc611fe597d5d39d18a2a03a
(cherry picked from commit 75c07a4fbd301fbff1522e66996bad91617cd06f)
Bug: 149990629
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
commit 6ade20327dbb808882888ed8ccded71e93067cf9 upstream.
find_vmap_area() can return a NULL pointer and we're going to
dereference it without checking it first. Use the existing
find_vm_area() function which does exactly what we want and checks for
the NULL pointer.
Link: http://lkml.kernel.org/r/20181228171009.22269-1-liviu@dudau.co.uk
Fixes: f3c01d2f3a ("mm: vmalloc: avoid racy handling of debugobjects in vunmap")
Signed-off-by: Liviu Dudau <liviu@dudau.co.uk>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Chintan Pandya <cpandya@codeaurora.org>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
There was hole to calculate memory consumption due to lacking
of GPU driver memory consumption.
This patch adds GPU driver memory consumption to vmstat.
It would be handy when we calculate memory.
Bug: 128254966
Bug: 130198686
Test: boot and check /proc/vmstat has nr_gpu_heap
Change-Id: Idb322f80dbfde785720f01b3ad9954eb4feb7326
(cherry picked from commit e6cbc72b7bd5816dfee130bc81c7cda903b4c6a3)
Signed-off-by: Minchan Kim <minchan@google.com>
Signed-off-by: Kyle Lin <kylelin@google.com>
Signed-off-by: Martin Liu <liumartin@google.com>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
mm_event_count function is used by modules like ION. Export it so
that the modules built separately can use it.
Bug: 149182139
Test: build and boot
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ic2f7f675989e50a70bb0595eb70903226a1dd4e2
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
