Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect

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

Re: [PATCH 6/7] psi: pressure stall information for CPU, memory, and IO

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(>clock

Re: [PATCH 6/7] psi: pressure stall information for CPU, memory, and IO

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(>clock

Re: [PATCH v10 18/25] mm: provide speculative fault infrastructure

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 >

Re: [PATCH v10 18/25] mm: provide speculative fault infrastructure

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 > + > +/* > + *

Re: [PATCH v10 06/25] mm: make pte_unmap_same compatible with SPF

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

Re: [PATCH v10 06/25] mm: make pte_unmap_same compatible with SPF

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

Re: [PATCH 6/7] psi: pressure stall information for CPU, memory, and IO

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

Re: [PATCH 6/7] psi: pressure stall information for CPU, memory, and IO

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

Re: [PATCH 1/3] mm: introduce NR_INDIRECTLY_RECLAIMABLE_BYTES

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

Re: [PATCH 1/3] mm: introduce NR_INDIRECTLY_RECLAIMABLE_BYTES

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

Re: [PATCHv2 08/14] mm/page_ext: Drop definition of unused PAGE_EXT_DEBUG_POISON

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 <kirill.shute...@linux.intel.com> > Cc: Vinayak

Re: [PATCHv2 08/14] mm/page_ext: Drop definition of unused PAGE_EXT_DEBUG_POISON

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

Re: [PATCH 1/1] stackdepot: interface to check entries and size of stackdepot.

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 

Re: [PATCH 1/1] stackdepot: interface to check entries and size of stackdepot.

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 

Re: Detecting page cache trashing state

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

Re: Detecting page cache trashing state

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

Re: [PATCH] Revert "mm: vmpressure: fix sending wrong events on underflow"

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

Re: [PATCH] Revert "mm: vmpressure: fix sending wrong events on underflow"

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. >> >> >>

Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup

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

Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup

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

Re: [RFC 1/1] mm, memcg: add prioritized reclaim

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

Re: [RFC 1/1] mm, memcg: add prioritized reclaim

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

Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup

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

Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup

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

[PATCH v6] mm: vmscan: do not pass reclaimed slab to vmpressure

from shrink_zone()") Link: http://lkml.kernel.org/r/1486641577-11685-2-git-send-email-vinme...@codeaurora.org Acked-by: Minchan Kim <minc...@kernel.org> Signed-off-by: Vinayak Menon <vinme...@codeaurora.org> Cc: Johannes Weiner <han...@cmpxchg.org> Cc: Mel Gorman <mgor...@tec

[PATCH v6] mm: vmscan: do not pass reclaimed slab to vmpressure

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 Vorontsov

Re: [PATCH 2/2 v5] mm: vmscan: do not pass reclaimed slab to vmpressure

On Thu, Feb 9, 2017 at 5:50 PM, Michal Hocko <mho...@kernel.org> 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 p

Re: [PATCH 2/2 v5] mm: vmscan: do not pass reclaimed slab to vmpressure

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 passe

[PATCH 2/2 v5] mm: vmscan: do not pass reclaimed slab to vmpressure

suse.com> Cc: Rik van Riel <r...@redhat.com> Cc: Vladimir Davydov <vdavydov@gmail.com> Cc: Anton Vorontsov <anton.voront...@linaro.org> Cc: Shiraz Hashim <shas...@codeaurora.org> Signed-off-by: Vinayak Menon <vinme...@codeaurora.org> --- v5: Modifying the change

[PATCH 2/2 v5] mm: vmscan: do not pass reclaimed slab to vmpressure

4f7799c6a5 ("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: Mod

[PATCH 1/2 v2] mm: vmpressure: fix sending wrong events on underflow

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 <minc...@kernel.org> Signed-off-by: Vinayak Menon <vinme...@codeaurora.org> --- v2: Addi

[PATCH 1/2 v2] mm: vmpressure: fix sending wrong events on underflow

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

Re: [PATCH 1/2 v4] mm: vmscan: do not pass reclaimed slab to vmpressure

On Tue, Feb 7, 2017 at 5:47 PM, Michal Hocko <mho...@kernel.org> wrote: > On Tue 07-02-17 16:39:15, vinayak menon wrote: >> On Tue, Feb 7, 2017 at 1:40 PM, Michal Hocko <mho...@kernel.org> wrote: >> > On Mon 06-02-17 20:40:10, vinayak menon wrote: >> >> On

Re: [PATCH 1/2 v4] mm: vmscan: do not pass reclaimed slab to vmpressure

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 w

Re: [PATCH 2/2 RESEND] mm: vmpressure: fix sending wrong events on underflow

On Mon, Feb 6, 2017 at 8:42 PM, Michal Hocko <mho...@kernel.org> 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 >

Re: [PATCH 2/2 RESEND] mm: vmpressure: fix sending wrong events on underflow

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

Re: [PATCH 1/2 v4] mm: vmscan: do not pass reclaimed slab to vmpressure

On Tue, Feb 7, 2017 at 1:40 PM, Michal Hocko <mho...@kernel.org> wrote: > On Mon 06-02-17 20:40:10, vinayak menon wrote: >> On Mon, Feb 6, 2017 at 6:22 PM, Michal Hocko <mho...@kernel.org> wrote: >> > On Mon 06-02-17 17:54:09, Vinayak Menon wrote: >> >&g

Re: [PATCH 1/2 v4] mm: vmscan: do not pass reclaimed slab to vmpressure

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

Re: [PATCH 1/2 v4] mm: vmscan: do not pass reclaimed slab to vmpressure

On Mon, Feb 6, 2017 at 6:22 PM, Michal Hocko <mho...@kernel.org> 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 >

Re: [PATCH 1/2 v4] mm: vmscan: do not pass reclaimed slab to 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.

Re: [PATCH 2/2 RESEND] mm: vmpressure: fix sending wrong events on underflow

On Mon, Feb 6, 2017 at 6:54 PM, Michal Hocko <mho...@kernel.org> wrote: > On Mon 06-02-17 18:39:03, vinayak menon wrote: >> On Mon, Feb 6, 2017 at 6:10 PM, Michal Hocko <mho...@kernel.org> wrote: >> > On Mon 06-02-17 17:54:10, Vinayak Menon wrote: >> > [...]

Re: [PATCH 2/2 RESEND] mm: vmpressure: fix sending wrong events on underflow

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.

Re: [PATCH 2/2 RESEND] mm: vmpressure: fix sending wrong events on underflow

On Mon, Feb 6, 2017 at 6:10 PM, Michal Hocko <mho...@kernel.org> 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

Re: [PATCH 2/2 RESEND] mm: vmpressure: fix sending wrong events on underflow

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

[PATCH 2/2 RESEND] mm: vmpressure: fix sending wrong events on underflow

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 <minc...@kernel.org> Signed-off-by: Vinayak Menon <vinme...@codeaurora.org> --- mm/vmpr

[PATCH 2/2 RESEND] mm: vmpressure: fix sending wrong events on underflow

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

[PATCH 1/2 v4] mm: vmscan: do not pass reclaimed slab to vmpressure

Vorontsov <anton.voront...@linaro.org> Cc: Shiraz Hashim <shas...@codeaurora.org> Signed-off-by: Vinayak Menon <vinme...@codeaurora.org> --- mm/vmscan.c | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 947ab6f..8969f8

[PATCH 1/2 v4] mm: vmscan: do not pass reclaimed slab to vmpressure

iner 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.c in

Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

On Fri, Feb 3, 2017 at 8:29 PM, Michal Hocko <mho...@kernel.org> wrote: > On Fri 03-02-17 10:56:42, vinayak menon wrote: >> On Thu, Feb 2, 2017 at 9:31 PM, Michal Hocko <mho...@kernel.org> wrote: >> > >> > Why would you like to chose and kill a task wh

Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

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 m

Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

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

Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

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

Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

On Thu, Feb 2, 2017 at 5:22 PM, Michal Hocko <mho...@kernel.org> wrote: > On Thu 02-02-17 16:55:49, vinayak menon wrote: >> On Thu, Feb 2, 2017 at 4:18 PM, Michal Hocko <mho...@kernel.org> wrote: >> > On Thu 02-02-17 11:44:22, Michal Hocko wrote: >> >> On

Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

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:

Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

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

Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

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

Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

On Thu, Feb 2, 2017 at 4:18 PM, Michal Hocko <mho...@kernel.org> 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 >> > inclu

Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

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

[PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

, 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 <vinme...@codeaurora.org> --- mm/vmscan.c | 17 - 1 file changed, 12

[PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

, 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(-)

Re: [PATCH 1/2 v2] mm: vmscan: do not pass reclaimed slab to vmpressure

On Tue, Jan 31, 2017 at 5:26 AM, Minchan Kim <minc...@kernel.org> 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 reclaim

Re: [PATCH 1/2 v2] mm: vmscan: do not pass reclaimed slab to vmpressure

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 t

[PATCH 2/2] mm: vmpressure: fix sending wrong events on underflow

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 <vinme...@codeaurora.org> --- mm/vmpressure.c | 5 - 1 file changed, 4 insertions

[PATCH 2/2] mm: vmpressure: fix sending wrong events on underflow

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

[PATCH 1/2 v2] mm: vmscan: do not pass reclaimed slab to vmpressure

-by: Vinayak Menon <vinme...@codeaurora.org> --- 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

[PATCH 1/2 v2] mm: vmscan: do not pass reclaimed slab to vmpressure

-by: 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

Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

> > 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.

Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

> > 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.

Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

Hi Minchan On Thu, Jan 26, 2017 at 4:57 AM, Minchan Kim <minc...@kernel.org> 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

Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

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

[PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

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

[PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

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

Re: [linux-mm] Drastic increase in application memory usage with Kernel version upgrade

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; >>

Re: [linux-mm] Drastic increase in application memory usage with Kernel version upgrade

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;

Re: [PATCH v1 3/3] mm: per-process reclaim

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

Re: [PATCH v1 3/3] mm: per-process reclaim

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

Re: [PATCH v1 0/3] per-process reclaim

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: [PATCH v1 0/3] per-process reclaim

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: [PATCH v1 0/3] per-process reclaim

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

Re: [PATCH v1 0/3] per-process reclaim

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

Re: [PATCH] mm: make fault_around_bytes configurable

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 <vinme...@codeaurora.org> >>> wrote: >>>

Re: [PATCH] mm: make fault_around_bytes configurable

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

Re: [PATCH] mm: make fault_around_bytes configurable

On 04/22/2016 05:31 AM, Andrew Morton wrote: On Mon, 18 Apr 2016 20:47:16 +0530 Vinayak Menon <vinme...@codeaurora.org> 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 som

Re: [PATCH] mm: make fault_around_bytes configurable

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

[PATCH] mm: make fault_around_bytes configurable

, there is 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 <vinme...@codeaurora.

[PATCH] mm: make fault_around_bytes configurable

, there is 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

[PATCH] of: alloc anywhere from memblock if range not specified

, for e.g. CMA. Let __memblock_alloc_base allocate from anywhere in memory if limits are not specified. Acked-by: Marek Szyprowski <m.szyprow...@samsung.com> Signed-off-by: Vinayak Menon <vinme...@codeaurora.org> --- drivers/of/of_reserved_mem.c | 4 +++- 1 file changed, 3 insertions(+)

[PATCH] of: alloc anywhere from memblock if range not specified

, 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

Re: [PATCH] mm/vmstat: retrieve more accurate vmstat value

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

Re: [PATCH] mm/vmstat: retrieve more accurate vmstat value

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

Re: [PATCH v2] mm: vmscan: fix the page state calculation in too_many_isolated

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

Re: [PATCH v2] mm: vmscan: fix the page state calculation in too_many_isolated

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

[PATCH] mm: compaction: fix the page state calculation in too_many_isolated

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

[PATCH] mm: compaction: fix the page state calculation in too_many_isolated

is performed. This patch fixes that. Signed-off-by: Vinayak Menon vinme...@codeaurora.org --- 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

Re: [PATCH v2] mm: vmscan: fix the page state calculation in too_many_isolated

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

Re: [PATCH v2] mm: vmscan: fix the page state calculation in too_many_isolated

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

Re: [PATCH v2] mm: vmscan: fix the page state calculation in too_many_isolated

: 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-state

Re: [PATCH v2] mm: vmscan: fix the page state calculation in too_many_isolated

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

Re: [PATCH v2] mm: vmscan: fix the page state calculation in too_many_isolated

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

  1   2   >