On Wed, Nov 18, 2020 at 07:19:07PM -0800, John Stultz wrote:
> On Wed, Nov 18, 2020 at 5:22 PM Hyesoo Yu wrote:
> >
> > On Tue, Nov 17, 2020 at 07:00:54PM -0800, John Stultz wrote:
> > > So I suspect Rob will push back on this as he has for other dt
> > > bindings related to ion/dmabuf heaps (I
comes up.
Cc: secur...@kernel.org
Fixes: ecb8ac8b1f14 ("mm/madvise: introduce process_madvise() syscall: an
external memory hinting API")
Reported-by: Jann Horn
Suggested-by: Jann Horn
Signed-off-by: Minchan Kim
---
mm/madvise.c | 3 +--
1 file changed, 1 insertion(+), 2 deletion
On Tue, Dec 08, 2020 at 09:26:55AM -0800, Minchan Kim wrote:
> On Mon, Dec 07, 2020 at 12:12:45PM +, Rui Salvaterra wrote:
> > From the beginning, the zram block device always enabled CRYPTO_LZO, since
> > lzo-rle is hardcoded as the fallback compression algorithm. As a
default algorithm is still lzo-rle.
>
> Suggested-by: Sergey Senozhatsky
> Suggested-by: Minchan Kim
> Signed-off-by: Rui Salvaterra
Acked-by: Minchan Kim
Thanks, Rui.
On Wed, Dec 02, 2020 at 09:22:36PM +0100, David Hildenbrand wrote:
> On 02.12.20 20:26, Minchan Kim wrote:
> > On Wed, Dec 02, 2020 at 07:51:07PM +0100, Michal Hocko wrote:
> >> On Wed 02-12-20 09:54:29, Minchan Kim wrote:
> >>> On Wed, Dec 02, 2020 at 05:48:
On Wed, Dec 02, 2020 at 07:51:07PM +0100, Michal Hocko wrote:
> On Wed 02-12-20 09:54:29, Minchan Kim wrote:
> > On Wed, Dec 02, 2020 at 05:48:34PM +0100, Michal Hocko wrote:
> > > On Wed 02-12-20 08:15:49, Minchan Kim wrote:
> > > > On Wed, Dec 02, 2020 at 04:49:
On Wed, Dec 02, 2020 at 05:48:34PM +0100, Michal Hocko wrote:
> On Wed 02-12-20 08:15:49, Minchan Kim wrote:
> > On Wed, Dec 02, 2020 at 04:49:15PM +0100, Michal Hocko wrote:
> [...]
> > > Well, what I can see is that this new interface is an antipatern to our
> > >
On Wed, Dec 02, 2020 at 04:49:15PM +0100, Michal Hocko wrote:
> On Wed 02-12-20 10:14:41, David Hildenbrand wrote:
> > On 01.12.20 18:51, Minchan Kim wrote:
> > > There is a need for special HW to require bulk allocation of
> > > high-order pages. For example,
On Wed, Dec 02, 2020 at 10:14:41AM +0100, David Hildenbrand wrote:
> On 01.12.20 18:51, Minchan Kim wrote:
> > There is a need for special HW to require bulk allocation of
> > high-order pages. For example, 4800 * order-4 pages, which
> > would be minimum, someti
On Tue, Dec 01, 2020 at 04:33:14PM -0800, John Stultz wrote:
> On Tue, Dec 1, 2020 at 4:13 PM Minchan Kim wrote:
> >
> > On Tue, Dec 01, 2020 at 03:38:14PM -0800, John Stultz wrote:
> > > On Tue, Dec 1, 2020 at 2:55 PM Minchan Kim wrote:
> > > > On Tue, De
On Tue, Dec 01, 2020 at 03:38:14PM -0800, John Stultz wrote:
> On Tue, Dec 1, 2020 at 2:55 PM Minchan Kim wrote:
> > On Tue, Dec 01, 2020 at 11:48:15AM -0800, John Stultz wrote:
> > > On Tue, Dec 1, 2020 at 9:51 AM Minchan Kim wrote:
> > >
> > >
On Tue, Dec 01, 2020 at 11:48:15AM -0800, John Stultz wrote:
> On Tue, Dec 1, 2020 at 9:51 AM Minchan Kim wrote:
>
> Thanks for reworking and resending this!
>
> ...
> > +static int __init chunk_heap_init(void)
> > +{
> > + struct cma *de
...@kernel.org/
* introduce alloc_contig_mode - David
* use default CMA instead of device tree - John
Hyesoo Yu (2):
dma-buf: add export symbol for dma-heap
dma-buf: heaps: add chunk heap to dmabuf heaps
Minchan Kim (2):
mm: introduce alloc_contig_mode
mm: introduce cma_alloc_bulk
ith "false" to increase success ratio
if they are okay to expense the overhead for the success ratio.
Signed-off-by: Minchan Kim
---
include/linux/cma.h | 5 ++
include/linux/gfp.h | 2 +
mm/cma.c| 126 ++--
mm/page_alloc.c | 19
the default CMA heap to allocate chunk
pages. We will add another CMA memory regions to the dmabuf heaps
interface with a later patch (which requires a dt binding)
[1] https://lore.kernel.org/patchwork/patch/1336002
Signed-off-by: Hyesoo Yu
Signed-off-by: Minchan Kim
---
drivers/dma-buf/heaps
Signed-off-by: Minchan Kim
---
drivers/dma-buf/dma-heap.c | 2 ++
kernel/dma/contiguous.c| 1 +
mm/cma.c | 5 +
3 files changed, 8 insertions(+)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index afd22c9dbdcf..cc6339cbca09 100644
--- a/drivers/dma-buf
.
Suggested-by: David Hildenbrand
Signed-off-by: Minchan Kim
---
drivers/virtio/virtio_mem.c | 2 +-
include/linux/gfp.h | 8 +++-
mm/cma.c| 3 ++-
mm/page_alloc.c | 6 --
4 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/virtio
.
Signed-off-by: Minchan Kim
---
Documentation/admin-guide/blockdev/zram.rst | 1 +
drivers/block/zram/zram_drv.c | 6 --
drivers/block/zram/zram_drv.h | 1 +
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/blockdev/zram.rst
b
On Thu, Nov 26, 2020 at 10:04:28PM +0900, Youngmin Nam wrote:
> Hi Minchan,
>
> Feel free to add my:
>
> Tested-by: Youngmin Nam
Thanks for the testing, Youngmin!
On Wed, Nov 25, 2020 at 03:23:40PM -0800, Suren Baghdasaryan wrote:
> On Wed, Nov 25, 2020 at 3:13 PM Minchan Kim wrote:
> >
> > On Mon, Nov 23, 2020 at 09:39:42PM -0800, Suren Baghdasaryan wrote:
> > > process_madvise requires a vector of address ranges to be provided
On Mon, Nov 23, 2020 at 09:39:42PM -0800, Suren Baghdasaryan wrote:
> process_madvise requires a vector of address ranges to be provided for
> its operations. When an advice should be applied to the entire process,
> the caller process has to obtain the list of VMAs of the target process
> by
the output
will be broken by shifting some bytes.
This patch fixes it.
Cc:
Fixes: 8e99cf91b99bb ("tracing: Do not allocate buffer in
trace_find_next_entry() in atomic")
Signed-off-by: Namhyung Kim
Signed-off-by: Minchan Kim
---
kernel/trace/trace.c | 2 +-
1 file changed, 1 insertion(+),
On Mon, Nov 23, 2020 at 06:41:14PM +, Will Deacon wrote:
> On Fri, Nov 20, 2020 at 07:55:14AM -0800, Minchan Kim wrote:
> > On Fri, Nov 20, 2020 at 04:00:23PM +0100, Peter Zijlstra wrote:
> > > On Fri, Nov 20, 2020 at 02:35:55PM +, Will Deacon wrote:
> > > > S
On Mon, Nov 23, 2020 at 06:13:34PM -0700, Yu Zhao wrote:
> On Mon, Nov 23, 2020 at 09:17:51PM +, Will Deacon wrote:
> > On Mon, Nov 23, 2020 at 01:04:03PM -0700, Yu Zhao wrote:
> > > On Mon, Nov 23, 2020 at 06:35:55PM +, Will Deacon wrote:
> > > > On Fri, Nov 20, 2020 at 01:40:05PM -0700,
On Mon, Nov 23, 2020 at 03:15:37PM +0100, David Hildenbrand wrote:
> On 17.11.20 19:19, Minchan Kim wrote:
> > There is a need for special HW to require bulk allocation of
> > high-order pages. For example, 4800 * order-4 pages, which
> > would be minimum, someti
default algorithm is still lzo-rle.
>
> Suggested-by: Sergey Senozhatsky
> Suggested-by: Minchan Kim
> Signed-off-by: Rui Salvaterra
Acked-by: Minchan Kim
Thanks, Rui!
On Fri, Nov 20, 2020 at 09:10:13AM +, Rui Salvaterra wrote:
> Hi, Minchan,
>
> On Thu, 19 Nov 2020 at 22:26, Minchan Kim wrote:
> >
> > What's the purpose of ZRAM_AUTOSEL_ALGO?
> > If you and Sergey already discussed, sorry about the missing it.
>
>
On Fri, Nov 20, 2020 at 02:35:53PM +, Will Deacon wrote:
> With hardware dirty bit management, calling pte_wrprotect() on a writable,
> dirty PTE will lose the dirty state and return a read-only, clean entry.
>
> Move the logic from ptep_set_wrprotect() into pte_wrprotect() to ensure that
>
lise the aging path, adjust pte_accessible() to return
> true for any valid pte, even if the access flag is cleared.
>
> Cc:
> Fixes: 76c714be0e5e ("arm64: pgtable: implement pte_accessible()")
> Reported-by: Yu Zhao
> Signed-off-by: Will Deacon
Reviewed-by: Minchan Kim
On Fri, Nov 20, 2020 at 04:00:23PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 20, 2020 at 02:35:55PM +, Will Deacon wrote:
> > Since commit 0758cd830494 ("asm-generic/tlb: avoid potential double flush"),
> > TLB invalidation is elided in tlb_finish_mmu() if no entries were batched
> > via the
On Thu, Nov 19, 2020 at 11:34:32AM +0800, Zhenhua Huang wrote:
> On Wed, Nov 04, 2020 at 07:27:03AM +0800, Minchan Kim wrote:
> > Sorry if this mail corrupts the mail thread or had heavy mangling
> > since I lost this mail from my mailbox so I am sending this mail by
> > web g
default algorithm is still lzo-rle.
>
> Suggested-by: Sergey Senozhatsky
> Suggested-by: Minchan Kim
> Signed-off-by: Rui Salvaterra
> ---
> v5: incorporate Minchan's feedback. Allow the user to choose a default
> algorithm.
> v4: incorporate Sergey's feedback and fix a s
On Thu, Nov 12, 2020 at 02:56:49PM -0800, Andrew Morton wrote:
> On Thu, 12 Nov 2020 18:26:24 +0530 Vijayanand Jitta
> wrote:
>
> > >> 1. page_owner=off, stackdepot_stack_hash=0 -> no more wasted memory
> > >> when we don't use page_owner
> > >> 2. page_owner=on, stackdepot_stack_hash=8M ->
On Tue, Nov 17, 2020 at 12:06:48PM -0800, Linus Torvalds wrote:
> On Mon, Nov 16, 2020 at 7:51 AM Minchan Kim wrote:
> >
> > Let me send a patch with your SoB if you don't mind.
>
> Eric, can you ack this SoB and I'll apply it to me tree?
>
> Or is it already queued
53ab22d0b0bdadd8d0 Mon Sep 17 00:00:00 2001
From: Minchan Kim
Date: Tue, 17 Nov 2020 11:58:51 -0800
Subject: [PATCH] mm/zsmalloc.c: drop ZSMALLOC_PGTABLE_MAPPING
Even though this option showed some amount improvement(e.g., 30%)
in some arm32 platforms, it has been headache to maintain since it
From: Hyesoo Yu
Document devicetree binding for chunk heap on dma heap framework
Signed-off-by: Hyesoo Yu
Signed-off-by: Minchan Kim
---
.../bindings/dma-buf/chunk_heap.yaml | 52 +++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree
Signed-off-by: Minchan Kim
---
drivers/dma-buf/dma-heap.c | 2 ++
mm/cma.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index afd22c9dbdcf..cc6339cbca09 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma
://lore.kernel.org/patchwork/patch/1336002
Signed-off-by: Hyesoo Yu
Signed-off-by: Minchan Kim
---
drivers/dma-buf/heaps/Kconfig | 9 +
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/chunk_heap.c | 458 +
3 files changed, 468 insertions(+)
create mode 100644
, they
could call it without __GFP_NORETRY to increase success ratio this time
if they are okay to expense the overhead for the success ratio.
Signed-off-by: Minchan Kim
---
include/linux/cma.h| 5 ++
include/linux/page-isolation.h | 1 +
mm/cma.c | 126
):
dma-buf: add export symbol for dma-heap
dma-buf: heaps: add chunk heap to dmabuf heaps
dma-heap: Devicetree binding for chunk heap
Minchan Kim (1):
mm: introduce cma_alloc_bulk API
.../bindings/dma-buf/chunk_heap.yaml | 52 ++
drivers/dma-buf/dma-heap.c
On Fri, Nov 13, 2020 at 06:16:32PM -0800, Andrew Morton wrote:
> On Fri, 13 Nov 2020 17:57:02 -0800 Suren Baghdasaryan
> wrote:
>
> > On Fri, Nov 13, 2020 at 5:18 PM Andrew Morton
> > wrote:
> > >
> > > On Fri, 13 Nov 2020 17:09:37 -0800 Suren Baghdasaryan
> > > wrote:
> > >
> > > > > > >
On Fri, Nov 13, 2020 at 08:25:29AM -0800, Minchan Kim wrote:
> On Thu, Nov 12, 2020 at 02:49:19PM -0800, Andrew Morton wrote:
> > On Thu, 12 Nov 2020 12:01:01 -0800 Minchan Kim wrote:
> >
> > >
> > > On Sat, Nov 07, 2020 at 12:39:39AM -0800, Min
On Mon, Nov 16, 2020 at 10:02:42AM +0100, Eric Dumazet wrote:
< snip >
> > From 02d63c6b3f61a1085f4eab80f5171bd2627b5ab0 Mon Sep 17 00:00:00 2001
> > From: Minchan Kim
> > Date: Mon, 21 Sep 2020 09:31:25 -0700
> > Subject: [PATCH] mm: do not use helper
On Thu, Nov 12, 2020 at 02:49:19PM -0800, Andrew Morton wrote:
> On Thu, 12 Nov 2020 12:01:01 -0800 Minchan Kim wrote:
>
> >
> > On Sat, Nov 07, 2020 at 12:39:39AM -0800, Minchan Kim wrote:
> > > Hi Andrew,
> > >
> > > On Fri, Nov 06,
Hi Andrew,
How should we proceed this problem?
On Sat, Nov 07, 2020 at 12:39:39AM -0800, Minchan Kim wrote:
> Hi Andrew,
>
> On Fri, Nov 06, 2020 at 05:59:33PM -0800, Andrew Morton wrote:
> > On Thu, 5 Nov 2020 09:02:49 -0800 Minchan Kim wrote:
> >
>
On Wed, Nov 11, 2020 at 03:33:18PM +0100, Arnd Bergmann wrote:
> On Wed, Nov 11, 2020 at 2:39 PM Thomas Bogendoerfer
> wrote:
> > On Wed, Nov 11, 2020 at 11:57:02AM +0100, Arnd Bergmann wrote:
> > > On Wed, Nov 11, 2020 at 11:26 AM Mike Rapoport wrote:
> > > >
> > > > On Wed, Nov 11, 2020 at
Hi,
On Wed, Nov 11, 2020 at 08:52:00AM +0200, Mike Rapoport wrote:
> Hi,
>
> On Tue, Nov 10, 2020 at 03:36:20PM -0800, Minchan Kim wrote:
> > On Tue, Nov 10, 2020 at 06:21:55PM +0200, Mike Rapoport wrote:
> > > On Tue, Nov 10, 2020 at 12:21:11PM +0100, Arnd Bergmann wrote
t neither those nor
> > 64-bit mode have so far made it into the kernel.
> >
> > To be on the safe side, we could provoke a compile-time error
> > when CONFIG_PHYS_ADDR_T_64BIT is set on a 32-bit
> > architecture, but MAX_POSSIBLE_PHYSMEM_BITS is not set.
>
> Mayb
On Sun, Nov 08, 2020 at 02:16:37AM +0100, Stefan Agner wrote:
> On 2020-11-08 01:56, Andrew Morton wrote:
> > On Sat, 7 Nov 2020 16:22:06 +0100 Stefan Agner wrote:
> >
> >> Most architectures define MAX_PHYSMEM_BITS in asm/sparsemem.h and don't
> >> include it in asm/pgtable.h. Include
On Mon, Nov 09, 2020 at 05:06:18PM +0100, Michal Hocko wrote:
> On Mon 09-11-20 07:39:33, Minchan Kim wrote:
> > On Mon, Nov 09, 2020 at 08:37:06AM +0100, Michal Hocko wrote:
> > > On Fri 06-11-20 12:32:38, Minchan Kim wrote:
> > > > It's hard to have some tests to b
On Mon, Nov 09, 2020 at 08:37:06AM +0100, Michal Hocko wrote:
> On Fri 06-11-20 12:32:38, Minchan Kim wrote:
> > It's hard to have some tests to be supposed to work under heavy
> > memory pressure(e.g., injecting some memory hogger) because
> > out-of-memory killer
Hi Andrew,
On Fri, Nov 06, 2020 at 05:59:33PM -0800, Andrew Morton wrote:
> On Thu, 5 Nov 2020 09:02:49 -0800 Minchan Kim wrote:
>
> > This reverts commit e47110e90584a22e9980510b00d0dfad3a83354e.
> >
> > While I was doing zram testing, I found sometimes decomp
On Fri, Nov 06, 2020 at 12:46:47PM -0800, Randy Dunlap wrote:
> Hi,
>
> Fix a few typos:
>
> On 11/6/20 12:32 PM, Minchan Kim wrote:
> > ---
> > Documentation/admin-guide/sysctl/vm.rst | 14 ++
> > include/linux/mm.h
we could mark existing process's oom_adj to -1000,
it couldn't cover upcoming processes to be forked for the job.
This knob is handy to keep system memory pressure.
Signed-off-by: Minchan Kim
---
Documentation/admin-guide/sysctl/vm.rst | 14 ++
include/linux/mm.h
On Thu, Nov 05, 2020 at 09:21:13AM -0800, Suren Baghdasaryan wrote:
> On Thu, Nov 5, 2020 at 9:16 AM Michal Hocko wrote:
> >
> > On Thu 05-11-20 08:50:58, Suren Baghdasaryan wrote:
> > > On Thu, Nov 5, 2020 at 4:20 AM Michal Hocko wrote:
> > > >
> >
On Thu, Nov 05, 2020 at 05:16:02PM +, Matthew Wilcox wrote:
> On Thu, Nov 05, 2020 at 09:02:49AM -0800, Minchan Kim wrote:
> > This reverts commit e47110e90584a22e9980510b00d0dfad3a83354e.
> >
> > While I was doing zram testing, I found sometimes decompression failed
>
On Thu, Nov 05, 2020 at 08:50:58AM -0800, Suren Baghdasaryan wrote:
> On Thu, Nov 5, 2020 at 4:20 AM Michal Hocko wrote:
> >
> > On Wed 04-11-20 12:40:51, Minchan Kim wrote:
> > > On Wed, Nov 04, 2020 at 07:58:44AM +0100, Michal Hocko wrote:
> > > > On Tue
e_list+0xb94/0xd60^M
[ 55.134626] shrink_inactive_list+0x158/0x460^M
Cc: Aneesh Kumar K.V
Cc: Harish Sriram
Cc:
Signed-off-by: Minchan Kim
---
mm/vmalloc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 6ae491a8b210..a4f1d39ce710 100644
--- a/mm/vma
On Wed, Nov 04, 2020 at 02:12:35PM +, Rui Salvaterra wrote:
> Hi, Minchan,
>
> On Tue, 3 Nov 2020 at 21:29, Minchan Kim wrote:
> >
> > Can't we just provide choice/endchoice in Kconfig to select default
> > comp algorithm from admin?
>
> I'm fine with what
On Wed, Nov 04, 2020 at 07:58:44AM +0100, Michal Hocko wrote:
> On Tue 03-11-20 13:32:28, Minchan Kim wrote:
> > On Tue, Nov 03, 2020 at 10:35:50AM +0100, Michal Hocko wrote:
> > > On Mon 02-11-20 12:29:24, Suren Baghdasaryan wrote:
> > > [...]
> > > > To
er, we want to have reasonable stackdeport hash array
With this configuration, it couldn't meet since we always need to
reserve a reasonable size for the array.
Can't we make the hash size as a kernel parameter?
With it, we could use it like this.
1. page_owner=off, stackdepot_stack_hash=0 -> no more wasted memory
when we don't use page_owner
2. page_owner=on, stackdepot_stack_hash=8M -> reasonable hash size
when we use page_owner.
--
Kind regards,
Minchan Kim
On Tue, Nov 03, 2020 at 01:40:41PM -0800, Suren Baghdasaryan wrote:
> On Tue, Nov 3, 2020 at 1:32 PM Minchan Kim wrote:
> >
> > On Tue, Nov 03, 2020 at 10:35:50AM +0100, Michal Hocko wrote:
> > > On Mon 02-11-20 12:29:24, Suren Baghdasaryan wrote:
> > > [...]
>
On Tue, Nov 03, 2020 at 10:35:50AM +0100, Michal Hocko wrote:
> On Mon 02-11-20 12:29:24, Suren Baghdasaryan wrote:
> [...]
> > To follow up on this. Should I post an RFC implementing SIGKILL_SYNC
> > which in addition to sending a kill signal would also reap the
> > victim's mm in the context of
Hi Sergey and Rui,
On Thu, Oct 29, 2020 at 03:59:27AM +0900, Sergey Senozhatsky wrote:
> Cc-ing Andrew
>
> message-id: 20201028115921.848-1-rsalvate...@gmail.com
>
> On (20/10/28 11:59), Rui Salvaterra wrote:
> > There's nothing special about zram and lzo. It works just fine without it,
> > so
page
writeback.
Cc: Sergey Senozhatsky
Signed-off-by: Minchan Kim
---
* from v1
* use "page_index=" signature for future extension - Sergey
Documentation/admin-guide/blockdev/zram.rst | 5 +
drivers/block/zram/zram_drv.c | 21 +
2 files c
jlstra (Intel)
> Tested-by: Mikhail Gavrilov
Acked-by: Minchan Kim
Thanks for the fix.
On Fri, Oct 16, 2020 at 05:38:26PM +0200, Vlastimil Babka wrote:
> On 10/13/20 10:09 AM, Mike Rapoport wrote:
> > > We are not complaining about TCP using too much memory, but how do
> > > we know that TCP uses a lot of memory. When I firstly face this problem,
> > > I do not know who uses the
Hi Sergey,
On Fri, Oct 16, 2020 at 09:25:47AM +0900, Sergey Senozhatsky wrote:
> On (20/10/12 00:14), Minchan Kim wrote:
> >
> > With the command, zram writeback idle pages from memory to the storage.
> >
> > +If admin want to write a specific page in zr
On Fri, Oct 16, 2020 at 02:40:09PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 16, 2020 at 11:21:47AM +0500, Mikhail Gavrilov wrote:
> > Hi folks,
> > today I joined to testing Kernel 5.10 and see that every boot happens
> > this warning:
> >
> > [9.032096]
On Thu, Oct 15, 2020 at 09:01:07AM -0400, Miaohe Lin wrote:
> Rework the list_add code to make it more readable and simplicity.
>
> Signed-off-by: Miaohe Lin
Acked-by: Minchan Kim
On Mon, Oct 12, 2020 at 02:04:00PM +0800, Yi Wang wrote:
> From: zhanglin
>
> Add max_num_devices to limit dynamic zram device creation to prevent
> potential OOM
>
> Signed-off-by: zhanglin
> Signed-off-by: Yi Wang
Acked-by: Minchan Kim
On Thu, Oct 15, 2020 at 11:20:30AM +0200, Michal Hocko wrote:
> > > I do have a vague recollection that we have discussed a kill(2) based
> > > approach as well in the past. Essentially SIG_KILL_SYNC which would
> > > not only send the signal but it would start a teardown of resources
> > > owned
writeback.
Cc: Sergey Senozhatsky
Signed-off-by: Minchan Kim
---
Documentation/admin-guide/blockdev/zram.rst | 5 +
drivers/block/zram/zram_drv.c | 14 ++
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/blockdev/zram.rst
b
The swap address_space doesn't have host. Thus, it makes kernel crash once
swap write meets error. Fix it.
[1] 735e4ae5ba28, vfs: track per-sb writeback errors and report them to syncfs
Signed-off-by: Minchan Kim
---
include/linux/pagemap.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
On Wed, Sep 23, 2020 at 10:16:25PM -0700, Chris Goldsworthy wrote:
> CMA allocations will fail if 'pinned' pages are in a CMA area, since we
> cannot migrate pinned pages. The _refcount of a struct page being greater
> than _mapcount for that page can cause pinning for anonymous pages. This
> is
On Mon, Sep 21, 2020 at 09:30:21AM +0800, Yi Wang wrote:
> From: zhanglin
>
> Add max_num_devices to limit dynamic zram device creation to prevent
> potential OOM
>
> Signed-off-by: zhanglin
> Signed-off-by: Yi Wang
> ---
> v1->v2:
> change hard-coded initial max_num_devices into
On Mon, Sep 21, 2020 at 08:17:08PM +0200, Christoph Hellwig wrote:
> On Mon, Sep 21, 2020 at 10:42:56AM -0700, Minchan Kim wrote:
> > IIRC, the problem was runtime pte popluating needs GFP_KERNEL but
> > zs_map_object API runs under non-preemtible section.
>
> Make sense
On Mon, Sep 21, 2020 at 07:56:33AM +0100, Christoph Hellwig wrote:
> On Mon, Aug 31, 2020 at 05:06:33PM -0700, Minchan Kim wrote:
> > There is usecase that System Management Software(SMS) want to give a
> > memory hint like MADV_[COLD|PAGEEOUT] to other processes and in the
>
On Fri, Sep 18, 2020 at 06:37:19PM +0200, Christoph Hellwig wrote:
> There is no obvious reason why zsmalloc needs to pre-fault the PTEs
> given that it later uses map_kernel_range to just like vmap().
IIRC, the problem was runtime pte popluating needs GFP_KERNEL but
zs_map_object API runs under
" so we can simply replace the old annotation
> with the new one.
>
> Signed-off-by: Douglas Anderson
Acked-by: Minchan Kim
91e86e81)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16e2a25590
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=164afdb390
>
> The issue was bisected to:
>
> commit 1a4e58cce84ee88129d5d49c064bd2852b481357
> Author: Minchan Kim
> Date
91e86e81)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16e2a25590
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=164afdb390
>
> The issue was bisected to:
>
> commit 1a4e58cce84ee88129d5d49c064bd2852b481357
> Author: Minchan Kim
> Date
Hi Yi,
On Fri, Sep 04, 2020 at 04:52:10PM +0800, Yi Wang wrote:
> From: zhanglin
>
> Add max_num_devices to limit dynamic zram device creation to prevent
> potential OOM
>
> Signed-off-by: zhanglin
> Signed-off-by: Yi Wang
> ---
> v1->v2:
> change hard-coded initial max_num_devices into
Hello, Yi,
On Tue, Sep 01, 2020 at 02:42:47PM +0800, Yi Wang wrote:
> From: zhanglin
>
> Add max_num_devices to limit dynamic zram device creation to prevent
> potential OOM
>
> Signed-off-by: zhanglin
> ---
> drivers/block/zram/zram_drv.c | 26 +++---
> 1 file changed,
On Thu, Sep 03, 2020 at 07:34:58PM +0200, Florian Weimer wrote:
> * Minchan Kim:
>
> > On Tue, Sep 01, 2020 at 08:46:02PM +0200, Florian Weimer wrote:
> >> * Minchan Kim:
> >>
> >> > ssize_t process_madvise(int pidfd, const struct iovec *iovec,
On Tue, Sep 01, 2020 at 08:46:02PM +0200, Florian Weimer wrote:
> * Minchan Kim:
>
> > ssize_t process_madvise(int pidfd, const struct iovec *iovec,
> > unsigned long vlen, int advice, unsigned int flags);
>
> size_t for vlen provides a clearer
g includes]
Link: http://lkml.kernel.org/r/20200622192900.22757-1-minc...@kernel.org
Link: http://lkml.kernel.org/r/20200302193630.68771-2-minc...@kernel.org
Link: http://lkml.kernel.org/r/20200622192900.22757-2-minc...@kernel.org
Signed-off-by: Minchan Kim
Reviewed-by: Suren Baghdasaryan
Reviewed-by: Vlastimil
x syscall number - SeongJae
* use get_pid_task - Kirill Tkhai
* extend API to support pid as well as pidfd - Kirill Tkhai
This patchset is against on v5.9-rc2-mmots-2020-08-30-18-40.
Minchan Kim (3):
mm/madvise: pass mm to do_madvise
pid: move pidfd_get_pid() to pid.c
mm/madvise: introduce
Baghdasaryan
Suggested-by: Alexander Duyck
Reviewed-by: Alexander Duyck
Acked-by: Christian Brauner
Reviewed-by: Vlastimil Babka
Acked-by: David Rientjes
Signed-off-by: Minchan Kim
Cc: Jens Axboe
Cc: Jann Horn
Cc: Brian Geffon
Cc: Daniel Colascione
Cc: Joel Fernandes
Cc: Johannes Weiner
Cc
http://lkml.kernel.org/r/20200508183320.ga125...@google.com
Link: http://lkml.kernel.org/r/20200622192900.22757-4-minc...@kernel.org
Reviewed-by: Suren Baghdasaryan
Reviewed-by: Vlastimil Babka
Acked-by: David Rientjes
Signed-off-by: Minchan Kim
Cc: Alexander Duyck
Cc: Brian Geffon
Cc: Christian Brauner
On Fri, Aug 28, 2020 at 08:25:34PM +0200, Christian Brauner wrote:
> On Fri, Aug 28, 2020 at 8:24 PM Jens Axboe wrote:
> >
> > On 8/28/20 11:40 AM, Arnd Bergmann wrote:
> > > On Mon, Jun 22, 2020 at 9:29 PM Minchan Kim wrote:
> > >> So finally, the API is as
On Fri, Aug 14, 2020 at 04:19:29AM +0100, Matthew Wilcox wrote:
> On Fri, Aug 14, 2020 at 10:45:37AM +0800, Zhaoyang Huang wrote:
> > On Fri, Aug 14, 2020 at 10:33 AM Andrew Morton
> > wrote:
> > >
> > > On Fri, 14 Aug 2020 10:20:11 +0800 Zhaoyang Huang
> > > wrote:
> > >
> > > > On Fri, Aug
On Sun, Jul 26, 2020 at 05:03:29PM +0200, Christoph Hellwig wrote:
> BDI_CAP_SYNCHRONOUS_IO is only checked in the swap code, and used to
> decided if ->rw_page can be used on a block device. Just check up for
> the method instead. The only complication is that zram needs a second
> set of
Thanks for Ccing me, Shakeel.
On Mon, Jul 20, 2020 at 10:52:55AM -0700, Shakeel Butt wrote:
> +Minchan Kim
>
> On Mon, Jul 20, 2020 at 12:52 AM Christoph Hellwig wrote:
> >
> > There is no point in trying to call bdev_read_page if SWP_SYNCHRONOUS_IO
> > is not set,
On Wed, Jun 24, 2020 at 01:00:14PM -0700, David Rientjes wrote:
> On Mon, 22 Jun 2020, Minchan Kim wrote:
>
> > diff --git a/mm/madvise.c b/mm/madvise.c
> > index 551ed816eefe..23abca3f93fa 100644
> > --- a/mm/madvise.c
> > +++ b/mm/madvise.c
> > @@ -17,6 +
Hi Oleksandr,
On Tue, Jun 23, 2020 at 11:07:21AM +0200, Oleksandr Natalenko wrote:
> On Mon, Jun 22, 2020 at 12:28:56PM -0700, Minchan Kim wrote:
> > Now, we have MADV_PAGEOUT and MADV_COLD as madvise hinting API. With that,
> > application could give hints to kernel wh
te static - gregkh]
>
> Reported-by: Wade Mealing
> Cc: stable
> Fixes: f40609d1591f ("zram: convert remaining CLASS_ATTR() to
> CLASS_ATTR_RO()")
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=1847832
> Signed-off-by: Greg Kroah-Hartman
Acked-by: Minchan Kim
On Mon, Jun 22, 2020 at 12:28:56PM -0700, Minchan Kim wrote:
> Now, we have MADV_PAGEOUT and MADV_COLD as madvise hinting API. With that,
> application could give hints to kernel what memory range are preferred to be
> reclaimed. However, in some platform(e.g., Android), the information
&
...@google.com
Signed-off-by: Minchan Kim
Reviewed-by: Suren Baghdasaryan
Reviewed-by: Vlastimil Babka
Cc: Alexander Duyck
Cc: Brian Geffon
Cc: Christian Brauner
Cc: Daniel Colascione
Cc: Jann Horn
Cc: Jens Axboe
Cc: Joel Fernandes
Cc: Johannes Weiner
Cc: John Dias
Cc: Kirill Tkhai
Cc: Mi
Bail out to prevent unnecessary CPU overhead if target process has pending
fatal signal during (MADV_COLD|MADV_PAGEOUT) operation.
Link: http://lkml.kernel.org/r/20200302193630.68771-4-minc...@kernel.org
Signed-off-by: Minchan Kim
Reviewed-by: Suren Baghdasaryan
Reviewed-by: Vlastimil Babka
Cc
201 - 300 of 6928 matches
Mail list logo
