Hi,
A crash was seen on 3.4.5 kernel during some random wlan operations.
CPU: Single core ARM Cortex A9.
fib_route_seq_next was called with second argument (void *v) as
0xd6e3e360 which is a "freed" object of the "ip_fib_trie" cache. I
confirmed that the object was freed with crash utility.
Seq
On Wed, Jul 31, 2013 at 6:43 PM, Hannes Frederic Sowa
wrote:
> On Wed, Jul 31, 2013 at 05:55:13AM -0700, Paul E. McKenney wrote:
>> On Wed, Jul 31, 2013 at 04:40:47PM +0530, vinayak menon wrote:
>> > Hi,
>> >
>> > A crash was seen on 3.4.5 kernel during some r
On Thu, Sep 28, 2017 at 9:19 PM, Ruslan Ruslichenko -X (rruslich -
GLOBALLOGIC INC at Cisco) wrote:
> Hi Johannes,
>
> Hopefully I was able to rebase the patch on top v4.9.26 (latest supported
> version by us right now)
> and test a bit.
> The overall idea definitely looks promising, although I ha
On Thu, Apr 12, 2018 at 8:27 PM, Roman Gushchin wrote:
> On Thu, Apr 12, 2018 at 08:52:52AM +0200, Vlastimil Babka wrote:
>> On 04/11/2018 03:56 PM, Roman Gushchin wrote:
>> > On Wed, Apr 11, 2018 at 03:16:08PM +0200, Vlastimil Babka wrote:
>> >> [+CC linux-api]
>> >>
>> >> On 03/05/2018 02:37 PM,
On 01/13/2015 09:39 PM, Johannes Weiner wrote:
On Tue, Jan 13, 2015 at 04:37:27PM +0530, Vinayak Menon wrote:
@@ -1392,6 +1392,44 @@ int isolate_lru_page(struct page *page)
return ret;
}
+static int __too_many_isolated(struct zone *zone, int file,
+ struct scan_control *sc, int
tasks were spinning in the
congestion wait loop for around 4 seconds, in the direct
reclaim path.
This patch uses zone_page_state_snapshot instead, but restricts
its usage to avoid performance penalty.
Signed-off-by: Vinayak Menon
---
mm/vmscan.c | 56 +---
On 01/14/2015 10:20 PM, Michal Hocko wrote:
On Wed 14-01-15 17:06:59, Vinayak Menon wrote:
[...]
In one such instance, zone_page_state(zone, NR_ISOLATED_FILE)
had returned 14, zone_page_state(zone, NR_INACTIVE_FILE)
returned 92, and GFP_IOFS was set, and this resulted
in too_many_isolated
tasks were spinning in the
congestion wait loop for around 4 seconds, in the direct
reclaim path.
This patch uses zone_page_state_snapshot instead, but restricts
its usage to avoid performance penalty.
Signed-off-by: Vinayak Menon
---
mm/vmscan.c | 68
On 01/16/2015 06:47 AM, Andrew Morton wrote:
On Wed, 14 Jan 2015 17:06:59 +0530 Vinayak Menon
wrote:
It is observed that sometimes multiple tasks get blocked for long
in the congestion_wait loop below, in shrink_inactive_list. This
is because of vm_stat values not being synced.
(__schedule
On 01/16/2015 09:19 PM, Michal Hocko wrote:
On Thu 15-01-15 22:54:20, Vinayak Menon wrote:
On 01/14/2015 10:20 PM, Michal Hocko wrote:
On Wed 14-01-15 17:06:59, Vinayak Menon wrote:
[...]
In one such instance, zone_page_state(zone, NR_ISOLATED_FILE)
had returned 14, zone_page_state(zone
.
Cc: Johannes Weiner
Cc: Mel Gorman
Cc: Michal Hocko
Cc: Minchan Kim
Cc: Vinayak Menon
Cc: Vladimir Davydov
Signed-off-by: Andrew Morton
---
mm/vmscan.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff -puN
mm/vmscan.c~mm-vmscan-fix-the-page-
On 01/18/2015 01:18 AM, Christoph Lameter wrote:
On Sat, 17 Jan 2015, Vinayak Menon wrote:
which had not updated the vmstat_diff. This CPU was in idle for around 30
secs. When I looked at the tvec base for this CPU, the timer associated with
vmstat_update had its expiry time less than current
On 01/26/2015 10:58 PM, Michal Hocko wrote:
On Sat 17-01-15 13:48:34, Christoph Lameter wrote:
On Sat, 17 Jan 2015, Vinayak Menon wrote:
which had not updated the vmstat_diff. This CPU was in idle for around 30
secs. When I looked at the tvec base for this CPU, the timer associated with
On 5/23/2018 6:47 PM, Johannes Weiner wrote:
> On Wed, May 09, 2018 at 04:33:24PM +0530, Vinayak Menon wrote:
>> On 5/8/2018 2:31 AM, Johannes Weiner wrote:
>>> + /* Kick the stats aggregation worker if it's gone to sleep */
>>> + if (!delayed_work_pending(&am
On 3/28/2018 10:25 PM, Kirill A. Shutemov wrote:
> After bd33ef368135 ("mm: enable page poisoning early at boot")
> PAGE_EXT_DEBUG_POISON is not longer used. Remove it.
>
> Signed-off-by: Kirill A. Shutemov
> Cc: Vinayak Menon
> ---
> include/linux/page_ext.h | 1
On Tue, Apr 17, 2018 at 8:03 PM, Laurent Dufour
wrote:
>
> +#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
> +
> +#ifndef __HAVE_ARCH_PTE_SPECIAL
> +/* This is required by vm_normal_page() */
> +#error "Speculative page fault handler requires __HAVE_ARCH_PTE_SPECIAL"
> +#endif
> +
> +/*
> + * vm_normal_page
On 1/5/2021 9:07 PM, Peter Zijlstra wrote:
On Mon, Dec 21, 2020 at 08:16:11PM -0800, Linus Torvalds wrote:
So I think the basic rule is that "if you hold mmap_sem for writing,
you're always safe". And that really should be considered the
"default" locking.
ANY time you make a modification to t
8/0x3b8)
Add a vm_fault handler which returns VM_FAULT_SIGBUS, and prevents the
wrong fallback to do_anonymous_page.
Signed-off-by: Vinayak Menon
---
drivers/staging/android/binder.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/android/binder.c b/
On Thu, Nov 26, 2015 at 7:26 AM, Joonsoo Kim wrote:
> On Wed, Nov 25, 2015 at 01:00:22PM +0100, Michal Hocko wrote:
>> On Tue 24-11-15 15:22:03, Joonsoo Kim wrote:
>> > When I tested compaction in low memory condition, I found that
>> > my benchmark is stuck in congestion_wait() at shrink_inactive
alculation is performed. This patch fixes that.
Signed-off-by: Vinayak Menon
---
mm/compaction.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 546e571..2d9730d 100644
--- a/mm/compaction.c
+++ b/mm/co
On 04/22/2016 05:31 AM, Andrew Morton wrote:
On Mon, 18 Apr 2016 20:47:16 +0530 Vinayak Menon
wrote:
Mapping pages around fault is found to cause performance degradation
in certain use cases. The test performed here is launch of 10 apps
one by one, doing something with the app each time, and
more pressure on reclaim because
of the presence of more mapped pages, resulting in more IO activity,
more faults, more swapping, and allocstalls.
Make fault_around_bytes configurable so that it can be tuned to avoid
performance degradation.
Signed-off-by: Vinayak Menon
---
mm/Kconfig | 10
On 4/22/2016 3:14 PM, Kirill A. Shutemov wrote:
> On Fri, Apr 22, 2016 at 02:15:08PM +0530, Vinayak Menon wrote:
>> On 04/22/2016 05:31 AM, Andrew Morton wrote:
>>> On Mon, 18 Apr 2016 20:47:16 +0530 Vinayak Menon
>>> wrote:
>>>
>>>> Mapping
On 5/8/2018 2:31 AM, Johannes Weiner wrote:
> +static void psi_group_update(struct psi_group *group, int cpu, u64 now,
> + unsigned int clear, unsigned int set)
> +{
> + enum psi_state state = PSI_NONE;
> + struct psi_group_cpu *groupc;
> + unsigned int *tasks;
On Tue, Apr 17, 2018 at 8:03 PM, Laurent Dufour
wrote:
> pte_unmap_same() is making the assumption that the page table are still
> around because the mmap_sem is held.
> This is no more the case when running a speculative page fault and
> additional check must be made to ensure that the final page
On Tue, Jan 31, 2017 at 5:26 AM, Minchan Kim wrote:
> On Fri, Jan 27, 2017 at 01:43:36PM +0530, Vinayak Menon wrote:
>> It is noticed that during a global reclaim the memory
>> reclaimed via shrinking the slabs can sometimes result
>> in reclaimed pages being greater than th
Also, not every shrinker accounts the pages it
reclaims. This is a regression introduced by commit 6b4f7799c6a5
("mm: vmscan: invoke slab shrinkers from shrink_zone()").
Signed-off-by: Vinayak Menon
---
mm/vmscan.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-
in a critical event being sent to
root cgroup. Fix this by not passing the reclaimed slab
count to vmpressure, with the assumption that vmpressure
should show the actual pressure on LRU which is now
diluted by adding reclaimed slab without a corresponding
scanned value.
Signed-off-by: Vinayak Menon
Hi Minchan
On Thu, Jan 26, 2017 at 4:57 AM, Minchan Kim wrote:
> Hello Vinayak,
>
> On Wed, Jan 25, 2017 at 05:08:38PM +0530, Vinayak Menon wrote:
>> It is noticed that during a global reclaim the memory
>> reclaimed via shrinking the slabs can sometimes result
>&g
>
> Thanks for the explain. However, such case can happen with THP page
> as well as slab. In case of THP page, nr_scanned is 1 but nr_reclaimed
> could be 512 so I think vmpressure should have a logic to prevent undeflow
> regardless of slab shrinking.
>
I see. Going to send a vmpressure fix. But,
: Vinayak Menon
---
mm/vmscan.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 947ab6f..37c4486 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2594,16 +2594,16 @@ static bool shrink_node(pg_data_t *pgdat, struct
scan_control *sc
a corresponding increment to scanned
pages. Minchan Kim mentioned that this can also happen in
the case of a THP page where the scanned is 1 and reclaimed
could be 512.
Signed-off-by: Vinayak Menon
---
mm/vmpressure.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/mm
On 6/15/2016 6:27 AM, Minchan Kim wrote:
>
> Yeb, I read Johannes's thread which suggests one-cgroup-per-app model.
> It does make sense to me. It is worth to try although I guess it's not
> easy to control memory usage on demand, not proactively.
> If we can do, maybe we don't need per-process re
On 3/20/2017 8:53 PM, Johannes Weiner wrote:
> On Mon, Mar 20, 2017 at 07:28:53PM +0530, Vinayak Menon wrote:
>> From the discussions @ https://lkml.org/lkml/2017/3/3/752, I assume you are
>> trying
>> per-app memcg. We were trying to implement per app memory cgroups and were
On Fri, Mar 17, 2017 at 04:16:35PM -0700, Tim Murray wrote:
Hi Tim,
>> Hi all,
>>
>> I've been working to improve Android's memory management and drop
>> lowmemorykiller from the kernel, and I'd like to get some feedback on a
>> small patch with a lot of side effects.
>>
>> Currently, when an
On Sat, Mar 18, 2017 at 4:46 AM, Tim Murray wrote:
> When a system is under memory pressure, it may be beneficial to prioritize
> some memory cgroups to keep their pages resident ahead of other cgroups'
> pages. Add a new interface to memory cgroups, memory.priority, that enables
> kswapd and dire
On 6/17/2016 12:54 PM, Balbir Singh wrote:
>
> On 14/06/16 01:06, Johannes Weiner wrote:
>> Hi Minchan,
>>
>> On Mon, Jun 13, 2016 at 04:50:58PM +0900, Minchan Kim wrote:
>>> These day, there are many platforms available in the embedded market
>>> and sometime, they has more hints about workingset
nkers from shrink_zone()")
Link:
http://lkml.kernel.org/r/1486641577-11685-2-git-send-email-vinme...@codeaurora.org
Acked-by: Minchan Kim
Signed-off-by: Vinayak Menon
Cc: Johannes Weiner
Cc: Mel Gorman
Cc: Vlastimil Babka
Cc: Michal Hocko
Cc: Rik van Riel
Cc: Vladimir Davydov
Cc: Anton Voront
On Fri, Feb 3, 2017 at 8:29 PM, Michal Hocko wrote:
> On Fri 03-02-17 10:56:42, vinayak menon wrote:
>> On Thu, Feb 2, 2017 at 9:31 PM, Michal Hocko wrote:
>> >
>> > Why would you like to chose and kill a task when the slab reclaim can
>> > still make suffi
es Weiner
Cc: Mel Gorman
Cc: Vlastimil Babka
Cc: Michal Hocko
Cc: Rik van Riel
Cc: Vladimir Davydov
Cc: Anton Vorontsov
Cc: Shiraz Hashim
Signed-off-by: Vinayak Menon
---
mm/vmscan.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan
a corresponding increment to scanned
pages. Minchan Kim mentioned that this can also happen in
the case of a THP page where the scanned is 1 and reclaimed
could be 512.
Acked-by: Minchan Kim
Signed-off-by: Vinayak Menon
---
mm/vmpressure.c | 5 -
1 file changed, 4 insertions(+), 1 deletion
On Mon, Feb 6, 2017 at 6:10 PM, Michal Hocko wrote:
> On Mon 06-02-17 17:54:10, Vinayak Menon wrote:
> [...]
>> diff --git a/mm/vmpressure.c b/mm/vmpressure.c
>> index 149fdf6..3281b34 100644
>> --- a/mm/vmpressure.c
>> +++ b/mm/vmpressure.c
>> @@ -112,8 +112
On Mon, Feb 6, 2017 at 6:54 PM, Michal Hocko wrote:
> On Mon 06-02-17 18:39:03, vinayak menon wrote:
>> On Mon, Feb 6, 2017 at 6:10 PM, Michal Hocko wrote:
>> > On Mon 06-02-17 17:54:10, Vinayak Menon wrote:
>> > [...]
>> >> diff --git a/mm/vmpressure.
On Mon, Feb 6, 2017 at 6:22 PM, Michal Hocko wrote:
> On Mon 06-02-17 17:54:09, Vinayak Menon wrote:
>> During global reclaim, the nr_reclaimed passed to vmpressure includes the
>> pages reclaimed from slab. But the corresponding scanned slab pages is
>> not passed.
On Tue, Feb 7, 2017 at 1:40 PM, Michal Hocko wrote:
> On Mon 06-02-17 20:40:10, vinayak menon wrote:
>> On Mon, Feb 6, 2017 at 6:22 PM, Michal Hocko wrote:
>> > On Mon 06-02-17 17:54:09, Vinayak Menon wrote:
>> >> During global reclaim, the nr_reclaimed pas
On Mon, Feb 6, 2017 at 8:42 PM, Michal Hocko wrote:
> On Mon 06-02-17 20:05:21, vinayak menon wrote:
> [...]
>> By scan I meant pages scanned by shrink_node_memcg/shrink_list
>> which is passed as nr_scanned to vmpressure. The calculation of
>> pressure for tr
On Tue, Feb 7, 2017 at 5:47 PM, Michal Hocko wrote:
> On Tue 07-02-17 16:39:15, vinayak menon wrote:
>> On Tue, Feb 7, 2017 at 1:40 PM, Michal Hocko wrote:
>> > On Mon 06-02-17 20:40:10, vinayak menon wrote:
>> >> On Mon, Feb 6, 2017 at 6:22 PM, Michal Hocko wrot
a corresponding increment to scanned
pages. Minchan Kim mentioned that this can also happen in
the case of a THP page where the scanned is 1 and reclaimed
could be 512.
Acked-by: Minchan Kim
Signed-off-by: Vinayak Menon
---
v2: Adding a comment and reordering the patches
as per Michal&#
s: 6b4f7799c6a5 ("mm: vmscan: invoke slab shrinkers from shrink_zone()")
Acked-by: Minchan Kim
Cc: Johannes Weiner
Cc: Mel Gorman
Cc: Vlastimil Babka
Cc: Michal Hocko
Cc: Rik van Riel
Cc: Vladimir Davydov
Cc: Anton Vorontsov
Cc: Shiraz Hashim
Signed-off-by: Vinayak Menon
---
v5: Mo
On Thu, Feb 9, 2017 at 5:50 PM, Michal Hocko wrote:
> On Thu 09-02-17 17:29:37, Vinayak Menon wrote:
>> During global reclaim, the nr_reclaimed passed to vmpressure includes the
>> pages reclaimed from slab. But the corresponding scanned slab pages is
>> not passed. Ther
On Thu, Feb 2, 2017 at 4:18 PM, Michal Hocko wrote:
> On Thu 02-02-17 11:44:22, Michal Hocko wrote:
>> On Tue 31-01-17 14:32:08, Vinayak Menon wrote:
>> > During global reclaim, the nr_reclaimed passed to vmpressure
>> > includes the pages reclaimed from slab. But the
On Thu, Feb 2, 2017 at 4:14 PM, Michal Hocko wrote:
>
> We usually refer to the culprit comment as
> Fixes: 6b4f7799c6a5 ("mm: vmscan: invoke slab shrinkers from shrink_zone()")
>
Thanks for pointing that out Michal. I see that added to the version
of patch in mmotm.
> To unsubscribe, send a mes
On Thu, Feb 2, 2017 at 5:22 PM, Michal Hocko wrote:
> On Thu 02-02-17 16:55:49, vinayak menon wrote:
>> On Thu, Feb 2, 2017 at 4:18 PM, Michal Hocko wrote:
>> > On Thu 02-02-17 11:44:22, Michal Hocko wrote:
>> >> On Tue 31-01-17 14:32:08, Vinayak Menon wrote:
>
On Thu, Feb 2, 2017 at 9:31 PM, Michal Hocko wrote:
>
> Why would you like to chose and kill a task when the slab reclaim can
> still make sufficient progres? Are you sure that the slab contribution
> to the stats makes all the above happening?
>
I agree that a task need not be killed if sufficien
On Wed, Aug 10, 2016 at 6:56 PM, PINTU KUMAR wrote:
> Hi,
>
>> -Original Message-
>> From: Pavel Machek [mailto:pa...@ucw.cz]
>> Sent: Saturday, August 06, 2016 2:20 AM
>> To: PINTU KUMAR
>> Cc: 'Minchan Kim'; linux-kernel@vger.kernel.org; linux...@kvack.org;
>> jaejoon@samsung.com; jy
On 6/13/2016 1:20 PM, Minchan Kim wrote:
> Hi all,
>
> http://thread.gmane.org/gmane.linux.kernel/1480728
>
> I sent per-process reclaim patchset three years ago. Then, last
> feedback from akpm was that he want to know real usecase scenario.
>
> Since then, I got question from several embedded peo
, for e.g. CMA.
Let __memblock_alloc_base allocate from anywhere in memory if limits are
not specified.
Acked-by: Marek Szyprowski
Signed-off-by: Vinayak Menon
---
drivers/of/of_reserved_mem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/of/of_reserved_mem.c b
On Wed, Jun 7, 2017 at 11:42 AM, Minchan Kim wrote:
> On Wed, Jun 07, 2017 at 12:56:57PM +0800, zhong jiang wrote:
>> On 2017/6/7 11:55, Minchan Kim wrote:
>> > On Wed, Jun 07, 2017 at 11:08:37AM +0800, zhongjiang wrote:
>> >> This reverts commit e1587a4945408faa58d0485002c110eb2454740c.
>> >>
>>
On 11/24/2017 7:00 PM, Vaneet Narang wrote:
> Hi Michal,
>
>>> We have been getting similar kind of such entries and eventually
>>> stackdepot reaches Max Cap. So we found this interface useful in debugging
>>> stackdepot issue so shared in community.
>
>> Then use it for internal debugging an
59 matches
Mail list logo
