Re: [PATCHv3 1/2] zsmalloc: introduce zs_huge_object() function

Hi Sergey, On Mon, Feb 26, 2018 at 02:49:27PM +0900, Sergey Senozhatsky wrote: > > I think it's simple enough. :) > > Right. The changes are pretty trivial, that's why I kept then in > 2 simple patches. Besides, I didn't want to mix zsmalloc and zram > changes. As I said earlier, it's not thing

Re: [PATCH RESEND 1/2] mm: swap: clean up swap readahead

On Mon, Feb 26, 2018 at 01:18:50PM +0800, Huang, Ying wrote: > Minchan Kim <minc...@kernel.org> writes: > > > On Fri, Feb 23, 2018 at 04:02:27PM +0800, Huang, Ying wrote: > >> <minc...@kernel.org> writes: > >> [snip] > >> > >> &

Re: [PATCH RESEND 1/2] mm: swap: clean up swap readahead

On Mon, Feb 26, 2018 at 01:18:50PM +0800, Huang, Ying wrote: > Minchan Kim writes: > > > On Fri, Feb 23, 2018 at 04:02:27PM +0800, Huang, Ying wrote: > >> writes: > >> [snip] > >> > >> > diff --git a/mm/swap_state.c b/mm/swap_sta

Re: [PATCH] mm: Fix races between address_space dereference and free in page_evicatable

Hi Jan, On Mon, Feb 19, 2018 at 11:57:35AM +0100, Jan Kara wrote: > Hi Minchan, > > On Sun 18-02-18 18:22:45, Minchan Kim wrote: > > On Mon, Feb 12, 2018 at 04:12:27PM +0800, Huang, Ying wrote: > > > From: Huang Ying <ying.hu...@intel.com> > > &g

Re: [PATCH] mm: Fix races between address_space dereference and free in page_evicatable

Hi Jan, On Mon, Feb 19, 2018 at 11:57:35AM +0100, Jan Kara wrote: > Hi Minchan, > > On Sun 18-02-18 18:22:45, Minchan Kim wrote: > > On Mon, Feb 12, 2018 at 04:12:27PM +0800, Huang, Ying wrote: > > > From: Huang Ying > > > > > > When page_mapping()

Re: [PATCH RESEND 1/2] mm: swap: clean up swap readahead

t THP page for readahead marker. Could't we relax the rule? I hope we can do so that we could remove PageTransCompound check for readahead marker, which makes code ugly. >From 748b084d5c3960ec2418d8c51a678aada30f1072 Mon Sep 17 00:00:00 2001 From: Minchan Kim <minc...@kernel.org>

Re: [PATCH RESEND 1/2] mm: swap: clean up swap readahead

page for readahead marker. Could't we relax the rule? I hope we can do so that we could remove PageTransCompound check for readahead marker, which makes code ugly. >From 748b084d5c3960ec2418d8c51a678aada30f1072 Mon Sep 17 00:00:00 2001 From: Minchan Kim Date: Mon, 26 Feb 2018 13:46:43 +0900 Subject: [PATCH] mm: re

[PATCH RESEND 2/2] mm: swap: unify cluster-based and vma-based swap readahead

From: Minchan Kim <minc...@kernel.org> This patch makes do_swap_page() not need to be aware of two different swap readahead algorithms. Just unify cluster-based and vma-based readahead function call. Link: http://lkml.kernel.org/r/1509520520-32367-3-git-send-email-minc...@kernel.org Sign

[PATCH RESEND 2/2] mm: swap: unify cluster-based and vma-based swap readahead

From: Minchan Kim This patch makes do_swap_page() not need to be aware of two different swap readahead algorithms. Just unify cluster-based and vma-based readahead function call. Link: http://lkml.kernel.org/r/1509520520-32367-3-git-send-email-minc...@kernel.org Signed-off-by: Minchan Kim Cc

[PATCH RESEND 1/2] mm: swap: clean up swap readahead

From: Minchan Kim <minc...@kernel.org> When I see recent change of swap readahead, I am very unhappy about current code structure which diverges two swap readahead algorithm in do_swap_page. This patch is to clean it up. Main motivation is that fault handler doesn't need to be

[PATCH RESEND 0/2] swap readahead clean up

From: Minchan Kim <minc...@kernel.org> This patchset cleans up recent added vma-based readahead code via unifying cluster-based readahead. Resent based on mmotm-2018-02-06-16-41. Minchan Kim (2): mm: swap: clean up swap readahead mm: swap: unify cluster-based and vma-based swap rea

[PATCH RESEND 1/2] mm: swap: clean up swap readahead

From: Minchan Kim When I see recent change of swap readahead, I am very unhappy about current code structure which diverges two swap readahead algorithm in do_swap_page. This patch is to clean it up. Main motivation is that fault handler doesn't need to be aware of readahead algorithms

[PATCH RESEND 0/2] swap readahead clean up

From: Minchan Kim This patchset cleans up recent added vma-based readahead code via unifying cluster-based readahead. Resent based on mmotm-2018-02-06-16-41. Minchan Kim (2): mm: swap: clean up swap readahead mm: swap: unify cluster-based and vma-based swap readahead include/linux/swap.h

Re: [PATCHv3 1/2] zsmalloc: introduce zs_huge_object() function

Hi Sergey, On Wed, Feb 14, 2018 at 02:57:47PM +0900, Sergey Senozhatsky wrote: > Not every object can be share its zspage with other objects, e.g. > when the object is as big as zspage or nearly as big a zspage. > For such objects zsmalloc has a so called huge class - every object > which belongs

Re: [PATCHv3 1/2] zsmalloc: introduce zs_huge_object() function

Hi Sergey, On Wed, Feb 14, 2018 at 02:57:47PM +0900, Sergey Senozhatsky wrote: > Not every object can be share its zspage with other objects, e.g. > when the object is as big as zspage or nearly as big a zspage. > For such objects zsmalloc has a so called huge class - every object > which belongs

Re: [PATCH] mm: Fix races between address_space dereference and free in page_evicatable

node? Let's cc linux-fs. > > Signed-off-by: "Huang, Ying" <ying.hu...@intel.com> > Cc: Mel Gorman <mgor...@techsingularity.net> > Cc: Minchan Kim <minc...@kernel.org> > Cc: "Huang, Ying" <ying.hu...@intel.com> > Cc: Jan Kara <j...@suse

Re: [PATCH] mm: Fix races between address_space dereference and free in page_evicatable

ce usage in rcu_read_lock/unlock(). Some comments are > added in code to make it clear what is protected by the RCU read lock. Is it always true for every FSes, even upcoming FSes? IOW, do we have any strict rule FS folks must use RCU(i.e., call_rcu) to destroy inode? Let's cc linux-fs. &

Re: [PATCH -mm -v2] mm, swap, frontswap: Fix THP swap if frontswap enabled

. > > > > Reported-and-tested-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com> > > Signed-off-by: "Huang, Ying" <ying.hu...@intel.com> > > Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > > Cc: Dan Streetman <ddstr...@ieee.org> >

Re: [PATCH -mm -v2] mm, swap, frontswap: Fix THP swap if frontswap enabled

writing the page to swap device > > if frontswap is enabled. To deal with the situation where frontswap > > is enabled at runtime, whether the page is THP is checked before using > > frontswap during swapping out too. > > > > Reported-and-tested-by: Sergey Senozhats

Re: [PATCH -mm -v2] mm, swap, frontswap: Fix THP swap if frontswap enabled

f (!frontswap_enabled()) { > > + if (IS_ENABLED(CONFIG_THP_SWAP)) > > + get_swap_pages(1, true, ); > > + } > > return entry; > > } > > I have proposed exactly the same thing [1], Minchan commen

Re: [PATCH -mm -v2] mm, swap, frontswap: Fix THP swap if frontswap enabled

f (!frontswap_enabled()) { > > + if (IS_ENABLED(CONFIG_THP_SWAP)) > > + get_swap_pages(1, true, ); > > + } > > return entry; > > } > > I have proposed exactly the same thing [1], Minchan commen

Re: [PATCH -mm -v2] mm, swap, frontswap: Fix THP swap if frontswap enabled

swapping out too. > > Reported-and-tested-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com> > Signed-off-by: "Huang, Ying" <ying.hu...@intel.com> > Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > Cc: Dan Streetman <ddstr...@ieee.org> > Cc: S

Re: [PATCH -mm -v2] mm, swap, frontswap: Fix THP swap if frontswap enabled

sted-by: Sergey Senozhatsky > Signed-off-by: "Huang, Ying" > Cc: Konrad Rzeszutek Wilk > Cc: Dan Streetman > Cc: Seth Jennings > Cc: Minchan Kim > Cc: Tetsuo Handa > Cc: Shaohua Li > Cc: Michal Hocko > Cc: Johannes Weiner > Cc: Mel Gorman >

Re: [PATCH RFC] ashmem: Fix lockdep RECLAIM_FS false positive

On Tue, Feb 06, 2018 at 02:32:13PM -0800, Joel Fernandes wrote: > Hi Minchan, > > On Tue, Feb 6, 2018 at 2:01 PM, Minchan Kim <minc...@kernel.org> wrote: > [...] > > On Mon, Feb 05, 2018 at 04:49:03PM -0800, Joel Fernandes wrote: > >> During invocation of ashm

Re: [PATCH RFC] ashmem: Fix lockdep RECLAIM_FS false positive

On Tue, Feb 06, 2018 at 02:32:13PM -0800, Joel Fernandes wrote: > Hi Minchan, > > On Tue, Feb 6, 2018 at 2:01 PM, Minchan Kim wrote: > [...] > > On Mon, Feb 05, 2018 at 04:49:03PM -0800, Joel Fernandes wrote: > >> During invocation of ashmem shrinker under memory

Re: [PATCH RFC] ashmem: Fix lockdep RECLAIM_FS false positive

Hi Joel, On Mon, Feb 05, 2018 at 04:49:03PM -0800, Joel Fernandes wrote: > During invocation of ashmem shrinker under memory pressure, ashmem > calls into VFS code via vfs_fallocate. We however make sure we > don't enter it if the allocation was GFP_FS to prevent looping > into filesystem code.

Re: [PATCH RFC] ashmem: Fix lockdep RECLAIM_FS false positive

Hi Joel, On Mon, Feb 05, 2018 at 04:49:03PM -0800, Joel Fernandes wrote: > During invocation of ashmem shrinker under memory pressure, ashmem > calls into VFS code via vfs_fallocate. We however make sure we > don't enter it if the allocation was GFP_FS to prevent looping > into filesystem code.

Re: [PATCH -mm] mm, swap, frontswap: Fix THP swap if frontswap enabled

On Tue, Feb 06, 2018 at 09:34:44PM +0800, huang ying wrote: > On Tue, Feb 6, 2018 at 5:02 PM, Minchan Kim <minc...@kernel.org> wrote: > > On Tue, Feb 06, 2018 at 04:39:18PM +0800, Huang, Ying wrote: > >> Hi, Minchan, > >> > >> Minchan Kim <min

Re: [PATCH -mm] mm, swap, frontswap: Fix THP swap if frontswap enabled

On Tue, Feb 06, 2018 at 09:34:44PM +0800, huang ying wrote: > On Tue, Feb 6, 2018 at 5:02 PM, Minchan Kim wrote: > > On Tue, Feb 06, 2018 at 04:39:18PM +0800, Huang, Ying wrote: > >> Hi, Minchan, > >> > >> Minchan Kim writes: > >> > >> > H

Re: [PATCH -mm] mm, swap, frontswap: Fix THP swap if frontswap enabled

Hi Sergey, On Tue, Feb 06, 2018 at 06:48:22PM +0900, Sergey Senozhatsky wrote: > Hello, > > On (02/06/18 01:02), Minchan Kim wrote: > [..] > > Can't we simple do like that if you want to make it simple and rely on > > someone > > who makes frontswap THP-aware l

Re: [PATCH -mm] mm, swap, frontswap: Fix THP swap if frontswap enabled

Hi Sergey, On Tue, Feb 06, 2018 at 06:48:22PM +0900, Sergey Senozhatsky wrote: > Hello, > > On (02/06/18 01:02), Minchan Kim wrote: > [..] > > Can't we simple do like that if you want to make it simple and rely on > > someone > > who makes frontswap THP-aware l

Re: [PATCH -mm] mm, swap, frontswap: Fix THP swap if frontswap enabled

On Tue, Feb 06, 2018 at 04:39:18PM +0800, Huang, Ying wrote: > Hi, Minchan, > > Minchan Kim <minc...@kernel.org> writes: > > > Hi Huang, > > > > On Tue, Feb 06, 2018 at 02:54:04PM +0800, Huang, Ying wrote: > >> From: Huang Ying <ying.hu...

Re: [PATCH -mm] mm, swap, frontswap: Fix THP swap if frontswap enabled

On Tue, Feb 06, 2018 at 04:39:18PM +0800, Huang, Ying wrote: > Hi, Minchan, > > Minchan Kim writes: > > > Hi Huang, > > > > On Tue, Feb 06, 2018 at 02:54:04PM +0800, Huang, Ying wrote: > >> From: Huang Ying > >> > >> It was rep

Re: [PATCH -mm] mm, swap, frontswap: Fix THP swap if frontswap enabled

tested-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com> > Signed-off-by: "Huang, Ying" <ying.hu...@intel.com> > Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > Cc: Dan Streetman <ddstr...@ieee.org> > Cc: Seth Jennings <sjenn...@redhat.com>

Re: [PATCH -mm] mm, swap, frontswap: Fix THP swap if frontswap enabled

ng a new dependency between frontswap and vmscan that I want to avoid if it is possible, let's think whether frontswap can support THP page or not. Can't we handle it with some loop to handle all of subpages of THP page? It might be not hard? > > Reported-and-tested-by: Sergey Senozhatsky

Re: [PATCH] mm: Pin address_space before dereferencing it while isolating an LRU page

On Thu, Jan 04, 2018 at 10:25:12AM +, Mel Gorman wrote: > Minchan Kim asked the following question -- what locks protects > address_space destroying when race happens between inode trauncation and > __isolate_lru_page? Jan Kara clarified by describing the race as follows

Re: [PATCH] mm: Pin address_space before dereferencing it while isolating an LRU page

On Thu, Jan 04, 2018 at 10:25:12AM +, Mel Gorman wrote: > Minchan Kim asked the following question -- what locks protects > address_space destroying when race happens between inode trauncation and > __isolate_lru_page? Jan Kara clarified by describing the race as follows

Re: [PATCH] zsmalloc: use U suffix for negative literals being shifted

Hi Nick, On Mon, Jan 08, 2018 at 08:35:19PM -0800, Nick Desaulniers wrote: > On Sun, Jan 7, 2018 at 7:04 AM, Minchan Kim <minc...@kernel.org> wrote: > > Sorry for the delay. I have missed this until now. ;-( > > No worries, figured patches would need a post ho

Re: [PATCH] zsmalloc: use U suffix for negative literals being shifted

Hi Nick, On Mon, Jan 08, 2018 at 08:35:19PM -0800, Nick Desaulniers wrote: > On Sun, Jan 7, 2018 at 7:04 AM, Minchan Kim wrote: > > Sorry for the delay. I have missed this until now. ;-( > > No worries, figured patches would need a post holiday bump for review. > > >

Re: [PATCH] zsmalloc: use U suffix for negative literals being shifted

Hello, Sorry for the delay. I have missed this until now. ;-( On Sun, Dec 24, 2017 at 11:33 AM, Nick Desaulniers wrote: > Fixes warnings about shifting unsigned literals being undefined > behavior. > > Signed-off-by: Nick Desaulniers >

Re: [PATCH] zsmalloc: use U suffix for negative literals being shifted

Hello, Sorry for the delay. I have missed this until now. ;-( On Sun, Dec 24, 2017 at 11:33 AM, Nick Desaulniers wrote: > Fixes warnings about shifting unsigned literals being undefined > behavior. > > Signed-off-by: Nick Desaulniers > --- > mm/zsmalloc.c | 2 +- > 1 file changed, 1

Re: [wrecked] mm-swap-unify-cluster-based-and-vma-based-swap-readahead.patch removed from -mm tree

wrecked this > patch > > ------ > From: Minchan Kim <minc...@kernel.org> > Subject: mm: swap: unify cluster-based and vma-based swap readahead > > This patch makes do_swap_page() not need to be aware of two different swap > readahead algorithms. Just uni

Re: [wrecked] mm-swap-unify-cluster-based-and-vma-based-swap-readahead.patch removed from -mm tree

wrecked this > patch > > ------ > From: Minchan Kim > Subject: mm: swap: unify cluster-based and vma-based swap readahead > > This patch makes do_swap_page() not need to be aware of two different swap > readahead algorithms. Just unify cluster-based and v

Re: [PATCH v2] zram: better utilization of zram swap space

On Thu, Dec 28, 2017 at 09:00:04AM +0900, Minchan Kim wrote: > On Wed, Dec 27, 2017 at 04:10:56PM +0900, Sergey Senozhatsky wrote: > > On (12/27/17 15:29), Minchan Kim wrote: > > > On Fri, Dec 22, 2017 at 04:00:06PM +0530, Gopi Sai Teja wrote: > > > > 75% of

Re: [PATCH v2] zram: better utilization of zram swap space

On Thu, Dec 28, 2017 at 09:00:04AM +0900, Minchan Kim wrote: > On Wed, Dec 27, 2017 at 04:10:56PM +0900, Sergey Senozhatsky wrote: > > On (12/27/17 15:29), Minchan Kim wrote: > > > On Fri, Dec 22, 2017 at 04:00:06PM +0530, Gopi Sai Teja wrote: > > > > 75% of

Re: [PATCH v2] zram: better utilization of zram swap space

On Wed, Dec 27, 2017 at 04:10:56PM +0900, Sergey Senozhatsky wrote: > On (12/27/17 15:29), Minchan Kim wrote: > > On Fri, Dec 22, 2017 at 04:00:06PM +0530, Gopi Sai Teja wrote: > > > 75% of the PAGE_SIZE is not a correct threshold to store uncompressed > > > >

Re: [PATCH v2] zram: better utilization of zram swap space

On Wed, Dec 27, 2017 at 04:10:56PM +0900, Sergey Senozhatsky wrote: > On (12/27/17 15:29), Minchan Kim wrote: > > On Fri, Dec 22, 2017 at 04:00:06PM +0530, Gopi Sai Teja wrote: > > > 75% of the PAGE_SIZE is not a correct threshold to store uncompressed > > > >

Re: [PATCH v2] zram: better utilization of zram swap space

Hello, On Fri, Dec 22, 2017 at 04:00:06PM +0530, Gopi Sai Teja wrote: > 75% of the PAGE_SIZE is not a correct threshold to store uncompressed Please describe it in detail that why current threshold is bad in that memory efficiency point of view. > pages in zs_page as this must be changed if the

Re: [PATCH v2] zram: better utilization of zram swap space

Hello, On Fri, Dec 22, 2017 at 04:00:06PM +0530, Gopi Sai Teja wrote: > 75% of the PAGE_SIZE is not a correct threshold to store uncompressed Please describe it in detail that why current threshold is bad in that memory efficiency point of view. > pages in zs_page as this must be changed if the

Re: [PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations

On Fri, Dec 22, 2017 at 10:14:43PM +0800, Huang, Ying wrote: > Minchan Kim <minc...@kernel.org> writes: > > > On Thu, Dec 21, 2017 at 03:48:56PM +0800, Huang, Ying wrote: > >> Minchan Kim <minc...@kernel.org> writes: > >> > >> > On We

Re: [PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations

On Fri, Dec 22, 2017 at 10:14:43PM +0800, Huang, Ying wrote: > Minchan Kim writes: > > > On Thu, Dec 21, 2017 at 03:48:56PM +0800, Huang, Ying wrote: > >> Minchan Kim writes: > >> > >> > On Wed, Dec 20, 2017 at 09:26:32AM +0800, H

Re: [PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations

On Thu, Dec 21, 2017 at 03:48:56PM +0800, Huang, Ying wrote: > Minchan Kim <minc...@kernel.org> writes: > > > On Wed, Dec 20, 2017 at 09:26:32AM +0800, Huang, Ying wrote: > >> From: Huang Ying <ying.hu...@intel.com> > >> > >> When the swapin is

Re: [PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations

On Thu, Dec 21, 2017 at 03:48:56PM +0800, Huang, Ying wrote: > Minchan Kim writes: > > > On Wed, Dec 20, 2017 at 09:26:32AM +0800, Huang, Ying wrote: > >> From: Huang Ying > >> > >> When the swapin is performed, after getting the swap entry infor

Re: [PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations

> swapoff, so this patch fixes the race between swap cache looking up > and swapoff too. > > Cc: Hugh Dickins <hu...@google.com> > Cc: Paul E. McKenney <paul...@linux.vnet.ibm.com> > Cc: Minchan Kim <minc...@kernel.org> > Cc: Johannes Weiner <han...@cmpxch

Re: [PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations

s the race between swap cache looking up > and swapoff too. > > Cc: Hugh Dickins > Cc: Paul E. McKenney > Cc: Minchan Kim > Cc: Johannes Weiner > Cc: Tim Chen > Cc: Shaohua Li > Cc: Mel Gorman > Cc: "Jérôme Glisse" > Cc: Michal Hocko > Cc:

Re: [PATCH -mm] mm, swap: Fix race between swapoff and some swap operations

Hi Huang, Sorry for the late response. I'm in middle of long vacation. On Fri, Dec 08, 2017 at 08:32:16PM +0800, Huang, Ying wrote: > Minchan Kim <minc...@kernel.org> writes: > > > On Fri, Dec 08, 2017 at 04:41:38PM +0800, Huang, Ying wrote: > >> Minchan Kim

Re: [PATCH -mm] mm, swap: Fix race between swapoff and some swap operations

Hi Huang, Sorry for the late response. I'm in middle of long vacation. On Fri, Dec 08, 2017 at 08:32:16PM +0800, Huang, Ying wrote: > Minchan Kim writes: > > > On Fri, Dec 08, 2017 at 04:41:38PM +0800, Huang, Ying wrote: > >> Minchan Kim writes: > >> > &

Re: [PATCH 1/1] zram: better utilization of zram swap space

Hi Gopi and Sergey, On Thu, Dec 07, 2017 at 05:45:10PM +0900, Sergey Senozhatsky wrote: > On (12/07/17 13:52), Gopi Sai Teja wrote: > > If the length of the compressed page is greater than 75% of the PAGE_SIZE, > > then the page is stored uncompressed in zram space. Zram space utilization > > is

Re: [PATCH 1/1] zram: better utilization of zram swap space

Hi Gopi and Sergey, On Thu, Dec 07, 2017 at 05:45:10PM +0900, Sergey Senozhatsky wrote: > On (12/07/17 13:52), Gopi Sai Teja wrote: > > If the length of the compressed page is greater than 75% of the PAGE_SIZE, > > then the page is stored uncompressed in zram space. Zram space utilization > > is

Re: [PATCH -mm] mm, swap: Fix race between swapoff and some swap operations

On Fri, Dec 08, 2017 at 04:41:38PM +0800, Huang, Ying wrote: > Minchan Kim <minc...@kernel.org> writes: > > > On Fri, Dec 08, 2017 at 01:41:10PM +0800, Huang, Ying wrote: > >> Minchan Kim <minc...@kernel.org> writes: > >> > >> > On Thu,

Re: [PATCH -mm] mm, swap: Fix race between swapoff and some swap operations

On Fri, Dec 08, 2017 at 04:41:38PM +0800, Huang, Ying wrote: > Minchan Kim writes: > > > On Fri, Dec 08, 2017 at 01:41:10PM +0800, Huang, Ying wrote: > >> Minchan Kim writes: > >> > >> > On Thu, Dec 07, 2017 at 04:29:37PM -0800, Andrew Morton wrote:

Re: [PATCH -mm] mm, swap: Fix race between swapoff and some swap operations

On Fri, Dec 08, 2017 at 01:41:10PM +0800, Huang, Ying wrote: > Minchan Kim <minc...@kernel.org> writes: > > > On Thu, Dec 07, 2017 at 04:29:37PM -0800, Andrew Morton wrote: > >> On Thu, 7 Dec 2017 09:14:26 +0800 "Huang, Ying" <ying.hu...@intel.com>

Re: [PATCH -mm] mm, swap: Fix race between swapoff and some swap operations

On Fri, Dec 08, 2017 at 01:41:10PM +0800, Huang, Ying wrote: > Minchan Kim writes: > > > On Thu, Dec 07, 2017 at 04:29:37PM -0800, Andrew Morton wrote: > >> On Thu, 7 Dec 2017 09:14:26 +0800 "Huang, Ying" > >> wrote: > >> > >> &g

Re: [PATCH -mm] mm, swap: Fix race between swapoff and some swap operations

On Thu, Dec 07, 2017 at 04:29:37PM -0800, Andrew Morton wrote: > On Thu, 7 Dec 2017 09:14:26 +0800 "Huang, Ying" wrote: > > > When the swapin is performed, after getting the swap entry information > > from the page table, the PTL (page table lock) will be released, then >

Re: [PATCH -mm] mm, swap: Fix race between swapoff and some swap operations

On Thu, Dec 07, 2017 at 04:29:37PM -0800, Andrew Morton wrote: > On Thu, 7 Dec 2017 09:14:26 +0800 "Huang, Ying" wrote: > > > When the swapin is performed, after getting the swap entry information > > from the page table, the PTL (page table lock) will be released, then > > system will go to

Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock

On Thu, Nov 30, 2017 at 12:47:36PM -0800, Andrew Morton wrote: > On Thu, 30 Nov 2017 08:54:04 -0500 Waiman Long wrote: > > > > And, from that perspective, the racy shortcut in the proposed patch > > > is wrong, too. Prefetch is fine, but in general shortcutting list > > >

Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock

On Thu, Nov 30, 2017 at 12:47:36PM -0800, Andrew Morton wrote: > On Thu, 30 Nov 2017 08:54:04 -0500 Waiman Long wrote: > > > > And, from that perspective, the racy shortcut in the proposed patch > > > is wrong, too. Prefetch is fine, but in general shortcutting list > > > empty checks outside

Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock

On Thu, Nov 30, 2017 at 08:43:41AM -0500, Waiman Long wrote: > On 11/29/2017 07:53 PM, Minchan Kim wrote: > > Hello, > > > > On Wed, Nov 29, 2017 at 09:17:34AM -0500, Waiman Long wrote: > >> The list_lru_del() function removes the given item from the LRU list. &

Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock

On Thu, Nov 30, 2017 at 08:43:41AM -0500, Waiman Long wrote: > On 11/29/2017 07:53 PM, Minchan Kim wrote: > > Hello, > > > > On Wed, Nov 29, 2017 at 09:17:34AM -0500, Waiman Long wrote: > >> The list_lru_del() function removes the given item from the LRU list. &

Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock

Hello, On Wed, Nov 29, 2017 at 09:17:34AM -0500, Waiman Long wrote: > The list_lru_del() function removes the given item from the LRU list. > The operation looks simple, but it involves writing into the cachelines > of the two neighboring list entries in order to get the deletion done. > That can

Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock

Hello, On Wed, Nov 29, 2017 at 09:17:34AM -0500, Waiman Long wrote: > The list_lru_del() function removes the given item from the LRU list. > The operation looks simple, but it involves writing into the cachelines > of the two neighboring list entries in order to get the deletion done. > That can

Re: [PATCH] mm/vmscan: make do_shrink_slab more robust.

On Mon, Nov 27, 2017 at 02:27:20PM +0800, jiang.bi...@zte.com.cn wrote: > > On Mon, Nov 27, 2017 at 12:46:27PM +0800, jiang.bi...@zte.com.cn wrote:> > > > On Mon, Nov 27, 2017 at 09:37:30AM +0800, Jiang Biao wrote:> > > > > > > This patch make do_shrink_slab more robust when > > > > >

Re: [PATCH] mm/vmscan: make do_shrink_slab more robust.

On Mon, Nov 27, 2017 at 02:27:20PM +0800, jiang.bi...@zte.com.cn wrote: > > On Mon, Nov 27, 2017 at 12:46:27PM +0800, jiang.bi...@zte.com.cn wrote:> > > > On Mon, Nov 27, 2017 at 09:37:30AM +0800, Jiang Biao wrote:> > > > > > > This patch make do_shrink_slab more robust when > > > > >

Re: [PATCH] mm: Do not stall register_shrinker

On Mon, Nov 27, 2017 at 11:16:46AM +0530, Anshuman Khandual wrote: > On 11/24/2017 05:34 AM, Minchan Kim wrote: > > Shakeel Butt reported, he have observed in production system that > > the job loader gets stuck for 10s of seconds while doing mount > > operation. It turns

Re: [PATCH] mm: Do not stall register_shrinker

On Mon, Nov 27, 2017 at 11:16:46AM +0530, Anshuman Khandual wrote: > On 11/24/2017 05:34 AM, Minchan Kim wrote: > > Shakeel Butt reported, he have observed in production system that > > the job loader gets stuck for 10s of seconds while doing mount > > operation. It turns

Re: [PATCH] mm/vmscan: make do_shrink_slab more robust.

On Mon, Nov 27, 2017 at 12:46:27PM +0800, jiang.bi...@zte.com.cn wrote: > On Mon, Nov 27, 2017 at 09:37:30AM +0800, Jiang Biao wrote:> > > > > This patch make do_shrink_slab more robust when > > > shrinker->count_objects return negative freeable. > > > > Shrinker.h says count_objects should

Re: [PATCH] mm/vmscan: make do_shrink_slab more robust.

On Mon, Nov 27, 2017 at 12:46:27PM +0800, jiang.bi...@zte.com.cn wrote: > On Mon, Nov 27, 2017 at 09:37:30AM +0800, Jiang Biao wrote:> > > > > This patch make do_shrink_slab more robust when > > > shrinker->count_objects return negative freeable. > > > > Shrinker.h says count_objects should

Re: [PATCH] mm/vmscan: make do_shrink_slab more robust.

Hello, On Mon, Nov 27, 2017 at 09:37:30AM +0800, Jiang Biao wrote: > When running ltp stress test for 7*24 hours, the kernel occasionally > complains the following warning continuously, > > mb_cache_shrink_scan+0x0/0x3f0 negative objects to delete > nr=-9222526086287711848 >

Re: [PATCH] mm/vmscan: make do_shrink_slab more robust.

Hello, On Mon, Nov 27, 2017 at 09:37:30AM +0800, Jiang Biao wrote: > When running ltp stress test for 7*24 hours, the kernel occasionally > complains the following warning continuously, > > mb_cache_shrink_scan+0x0/0x3f0 negative objects to delete > nr=-9222526086287711848 >

Re: Detecting page cache trashing state

Hello, On Mon, Nov 20, 2017 at 09:40:56PM +0200, Ruslan Ruslichenko -X (rruslich - GLOBALLOGIC INC at Cisco) wrote: > Hi Johannes, > > I tested with your patches but situation is still mostly the same. > > Spend some time for debugging and found that the problem is squashfs > specific

Re: Detecting page cache trashing state

Hello, On Mon, Nov 20, 2017 at 09:40:56PM +0200, Ruslan Ruslichenko -X (rruslich - GLOBALLOGIC INC at Cisco) wrote: > Hi Johannes, > > I tested with your patches but situation is still mostly the same. > > Spend some time for debugging and found that the problem is squashfs > specific

[PATCH] mm: Do not stall register_shrinker

-ker...@i-love.sakura.ne.jp> Acked-by: Johannes Weiner <han...@cmpxchg.org> Reported-and-tested-by: Shakeel Butt <shake...@google.com> Signed-off-by: Shakeel Butt <shake...@google.com> Signed-off-by: Minchan Kim <minc...@kernel.org> --- mm/vmscan.c | 8 1 file chang

[PATCH] mm: Do not stall register_shrinker

-and-tested-by: Shakeel Butt Signed-off-by: Shakeel Butt Signed-off-by: Minchan Kim --- mm/vmscan.c | 8 1 file changed, 8 insertions(+) diff --git a/mm/vmscan.c b/mm/vmscan.c index 6a5a72baccd5..6698001787bd 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -486,6 +486,14 @@ static unsigned long

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

On Thu, Nov 16, 2017 at 12:44:22PM -0500, Johannes Weiner wrote: > On Wed, Nov 15, 2017 at 09:56:02AM +0900, Minchan Kim wrote: > > @@ -498,6 +498,14 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int > > nid, > > sc.nid = 0; > > > >

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

On Thu, Nov 16, 2017 at 12:44:22PM -0500, Johannes Weiner wrote: > On Wed, Nov 15, 2017 at 09:56:02AM +0900, Minchan Kim wrote: > > @@ -498,6 +498,14 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int > > nid, > > sc.nid = 0; > > > >

Re: [PATCH] arch, mm: introduce arch_tlb_gather_mmu_lazy

g down the > > > > > entire address space. > > > > > > > > OK, that makes sense. > > > > > > > > > Alternatively, I could actually go check MMF_UNSTABLE in tlb->mm, > > > > > which > > > > > would

Re: [PATCH] arch, mm: introduce arch_tlb_gather_mmu_lazy

g down the > > > > > entire address space. > > > > > > > > OK, that makes sense. > > > > > > > > > Alternatively, I could actually go check MMF_UNSTABLE in tlb->mm, > > > > > which > > > > > would

Re: linux-next: manual merge of the akpm-current tree with the nvdimm tree

Hi Stephen, On Thu, Nov 16, 2017 at 02:16:27PM +1100, Stephen Rothwell wrote: > Hi Andrew, > > Today's linux-next merge of the akpm-current tree got a conflict in: > > drivers/block/brd.c > > between commit: > > 7a862fbbdec6 ("brd: remove dax support") > > from the nvdimm tree and

Re: linux-next: manual merge of the akpm-current tree with the nvdimm tree

Hi Stephen, On Thu, Nov 16, 2017 at 02:16:27PM +1100, Stephen Rothwell wrote: > Hi Andrew, > > Today's linux-next merge of the akpm-current tree got a conflict in: > > drivers/block/brd.c > > between commit: > > 7a862fbbdec6 ("brd: remove dax support") > > from the nvdimm tree and

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

On Wed, Nov 15, 2017 at 05:41:41PM -0800, Shakeel Butt wrote: > On Wed, Nov 15, 2017 at 4:46 PM, Minchan Kim <minc...@kernel.org> wrote: > > On Tue, Nov 14, 2017 at 10:28:10PM -0800, Shakeel Butt wrote: > >> On Tue, Nov 14, 2017 at 4:56 PM, Minchan Kim <minc...@kerne

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

On Wed, Nov 15, 2017 at 05:41:41PM -0800, Shakeel Butt wrote: > On Wed, Nov 15, 2017 at 4:46 PM, Minchan Kim wrote: > > On Tue, Nov 14, 2017 at 10:28:10PM -0800, Shakeel Butt wrote: > >> On Tue, Nov 14, 2017 at 4:56 PM, Minchan Kim wrote: > >> > On Tue, Nov 14, 20

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

On Wed, Nov 15, 2017 at 12:51:43PM +0100, Michal Hocko wrote: < snip > > > Since it is possible for a local unpriviledged user to lockup the system at > > least > > due to mute_trylock(_lock) versus (printk() or > > schedule_timeout_killable(1)), > > I suggest completely eliminating scheduling

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

On Wed, Nov 15, 2017 at 12:51:43PM +0100, Michal Hocko wrote: < snip > > > Since it is possible for a local unpriviledged user to lockup the system at > > least > > due to mute_trylock(_lock) versus (printk() or > > schedule_timeout_killable(1)), > > I suggest completely eliminating scheduling

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

On Tue, Nov 14, 2017 at 10:28:10PM -0800, Shakeel Butt wrote: > On Tue, Nov 14, 2017 at 4:56 PM, Minchan Kim <minc...@kernel.org> wrote: > > On Tue, Nov 14, 2017 at 06:37:42AM +0900, Tetsuo Handa wrote: > >> When shrinker_rwsem was introduced, it was assumed tha

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

On Tue, Nov 14, 2017 at 10:28:10PM -0800, Shakeel Butt wrote: > On Tue, Nov 14, 2017 at 4:56 PM, Minchan Kim wrote: > > On Tue, Nov 14, 2017 at 06:37:42AM +0900, Tetsuo Handa wrote: > >> When shrinker_rwsem was introduced, it was assumed that > >> register_shr

Re: [PATCH] arch, mm: introduce arch_tlb_gather_mmu_lazy (was: Re: [RESEND PATCH] mm, oom_reaper: gather each vma to prevent) leaking TLB entry

On Wed, Nov 15, 2017 at 09:14:52AM +0100, Michal Hocko wrote: > On Mon 13-11-17 09:28:33, Minchan Kim wrote: > [...] > > void arch_tlb_gather_mmu(...) > > > > tlb->fullmm = !(start | (end + 1)) && atomic_read(>mm_users) == > >

Re: [PATCH] arch, mm: introduce arch_tlb_gather_mmu_lazy (was: Re: [RESEND PATCH] mm, oom_reaper: gather each vma to prevent) leaking TLB entry

On Wed, Nov 15, 2017 at 09:14:52AM +0100, Michal Hocko wrote: > On Mon 13-11-17 09:28:33, Minchan Kim wrote: > [...] > > void arch_tlb_gather_mmu(...) > > > > tlb->fullmm = !(start | (end + 1)) && atomic_read(>mm_users) == > >

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

On Tue, Nov 14, 2017 at 06:37:42AM +0900, Tetsuo Handa wrote: > When shrinker_rwsem was introduced, it was assumed that > register_shrinker()/unregister_shrinker() are really unlikely paths > which are called during initialization and tear down. But nowadays, >

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

On Tue, Nov 14, 2017 at 06:37:42AM +0900, Tetsuo Handa wrote: > When shrinker_rwsem was introduced, it was assumed that > register_shrinker()/unregister_shrinker() are really unlikely paths > which are called during initialization and tear down. But nowadays, >

Re: [PATCH] arch, mm: introduce arch_tlb_gather_mmu_lazy (was: Re: [RESEND PATCH] mm, oom_reaper: gather each vma to prevent) leaking TLB entry

On Tue, Nov 14, 2017 at 08:21:00AM +0100, Michal Hocko wrote: > On Tue 14-11-17 10:45:49, Minchan Kim wrote: > [...] > > Anyway, I think Wang Nan's patch is already broken. > > http://lkml.kernel.org/r/%3c20171107095453.179940-1-wangn...@huawei.com%3E > > > &g

<    5   6   7   8   9   10   11   12   13   14   >