/mm/cma/BLUETOOTH/cma_alloc_pages_[attempts|fails]
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: John Hubbard
Signed-off-by: Minchan Kim
---
>From v2 -
>https://lore.kernel.org/linux-mm/20210208180142.2765456-1-minc...@kernel.org/
* sysfs doc and description modification - jhubbard
&g
putback_lru_pages to put_page[1].
This patch removes it.
[1] c6c919eb90e0, ("mm: use put_page() to free page instead of
putback_lru_page()"
Reviewed-by: Oscar Salvador
Acked-by: Vlastimil Babka
Acked-by: Michal Hocko
Signed-off-by: Minchan Kim
---
* From v1 -
https://lore.kernel.or
On Wed, Mar 03, 2021 at 01:49:36PM +0100, Michal Hocko wrote:
> On Tue 02-03-21 13:09:48, Minchan Kim wrote:
> > LRU pagevec holds refcount of pages until the pagevec are drained.
> > It could prevent migration since the refcount of the page is greater
> > than the expecti
500 during the testing. With this patch, the dump_page count
was reduced from 400 to 30.
Signed-off-by: Minchan Kim
---
* from RFC -
http://lore.kernel.org/linux-mm/20210216170348.1513483-1-minc...@kernel.org
* use atomic and lru_add_drain_all for strict ordering - mhocko
* lru_cache_disable/enable
being cached in the LRU caches,
until migration has finished.
Suggested-by: Matthew Wilcox
Signed-off-by: Chris Goldsworthy
Signed-off-by: Minchan Kim
---
* from prev -
https://lore.kernel.org/linux-mm/e8f3e042b902156467a5e978b57c14954213ec59.1611642039.git.cgold...@codeaurora.org
Since CMA is used more widely, it's worth to have CMA
allocation statistics into vmstat. With it, we could
know how agressively system uses cma allocation and
how often it fails.
Signed-off-by: Minchan Kim
---
* from v1 -
https://lore.kernel.org/linux-mm/20210217170025.512704-1-minc
On Fri, Feb 19, 2021 at 10:28:12AM +0100, Michal Hocko wrote:
> On Thu 18-02-21 08:19:50, Minchan Kim wrote:
> > On Thu, Feb 18, 2021 at 10:43:21AM +0100, David Hildenbrand wrote:
> > > On 18.02.21 10:35, Michal Hocko wrote:
> > > > On Thu 18-02-21 10:
give us a better reason why
> alloc_contig_range() failed on specific pages.
>
> Cc: Andrew Morton
> Cc: Minchan Kim
> Cc: Oscar Salvador
> Cc: Michal Hocko
> Cc: Vlastimil Babka
> Signed-off-by: David Hildenbrand
I agree it's not useful to dump just range. Rather than, dump_page
would be much helpful.
Acked-by: Minchan Kim
On Thu, Feb 18, 2021 at 05:26:08PM +0100, David Hildenbrand wrote:
> On 18.02.21 17:19, Minchan Kim wrote:
> > On Thu, Feb 18, 2021 at 10:43:21AM +0100, David Hildenbrand wrote:
> > > On 18.02.21 10:35, Michal Hocko wrote:
> > > > On Thu 18-02-21 10:
On Thu, Feb 18, 2021 at 05:08:58PM +0100, Michal Hocko wrote:
> On Thu 18-02-21 07:52:25, Minchan Kim wrote:
> > On Thu, Feb 18, 2021 at 09:17:02AM +0100, Michal Hocko wrote:
> > > On Wed 17-02-21 13:32:05, Minchan Kim wrote:
> > > > On Wed, Feb 17, 2021 at 09:16:12
On Thu, Feb 18, 2021 at 10:43:21AM +0100, David Hildenbrand wrote:
> On 18.02.21 10:35, Michal Hocko wrote:
> > On Thu 18-02-21 10:02:43, David Hildenbrand wrote:
> > > On 18.02.21 09:56, Michal Hocko wrote:
> > > > On Wed 17-02-21 08:36:03, Minchan Kim wrote
On Thu, Feb 18, 2021 at 09:56:18AM +0100, Michal Hocko wrote:
> On Wed 17-02-21 08:36:03, Minchan Kim wrote:
> > alloc_contig_range is usually used on cma area or movable zone.
> > It's critical if the page migration fails on those areas so
> > dump more debugging messag
On Thu, Feb 18, 2021 at 09:17:02AM +0100, Michal Hocko wrote:
> On Wed 17-02-21 13:32:05, Minchan Kim wrote:
> > On Wed, Feb 17, 2021 at 09:16:12PM +, Matthew Wilcox wrote:
> > > On Wed, Feb 17, 2021 at 12:46:19PM -0800, Minchan Kim wrote:
> > > > > I suspect y
On Wed, Feb 17, 2021 at 09:16:12PM +, Matthew Wilcox wrote:
> On Wed, Feb 17, 2021 at 12:46:19PM -0800, Minchan Kim wrote:
> > > I suspect you do not want to add atomic_read inside hot paths, right? Is
> > > this really something that we have to microoptimize for? atomic_r
On Wed, Feb 17, 2021 at 09:11:43PM +, Matthew Wilcox wrote:
> On Wed, Feb 17, 2021 at 12:51:25PM -0800, Minchan Kim wrote:
> > I'd like to avoid atomic operation if we could.
>
> Why do you think that the spinlock is better?
>
Michal suggested atomic_inc in writesi
On Wed, Feb 17, 2021 at 12:57:25PM -0800, John Hubbard wrote:
> On 2/17/21 9:00 AM, Minchan Kim wrote:
> > Since CMA is used more widely, it's worth to have CMA
> > allocation statistics into vmstat. With it, we could
> > know how agressively system uses cma allocation and
&
On Wed, Feb 17, 2021 at 10:50:55AM +0100, Michal Hocko wrote:
> On Wed 17-02-21 09:59:54, Michal Hocko wrote:
> > On Tue 16-02-21 09:03:47, Minchan Kim wrote:
> [...]
> > > /*
> > > * migrate_prep() needs to be called before we start compiling a list of
> &
On Wed, Feb 17, 2021 at 09:59:54AM +0100, Michal Hocko wrote:
> On Tue 16-02-21 09:03:47, Minchan Kim wrote:
> > LRU pagevec holds refcount of pages until the pagevec are drained.
> > It could prevent migration since the refcount of the page is greater
> > than the expecti
On Wed, Feb 17, 2021 at 06:34:13PM +0100, David Hildenbrand wrote:
> On 17.02.21 18:26, Minchan Kim wrote:
> > On Wed, Feb 17, 2021 at 05:51:27PM +0100, David Hildenbrand wrote:
> > > On 17.02.21 17:36, Minchan Kim wrote:
> > > > alloc_contig_range is usually us
On Wed, Feb 17, 2021 at 05:51:27PM +0100, David Hildenbrand wrote:
> On 17.02.21 17:36, Minchan Kim wrote:
> > alloc_contig_range is usually used on cma area or movable zone.
> > It's critical if the page migration fails on those areas so
> > dump more debugging message like
Since CMA is used more widely, it's worth to have CMA
allocation statistics into vmstat. With it, we could
know how agressively system uses cma allocation and
how often it fails.
Signed-off-by: Minchan Kim
---
include/linux/vm_event_item.h | 3 +++
mm/cma.c | 12
alloc_contig_range is usually used on cma area or movable zone.
It's critical if the page migration fails on those areas so
dump more debugging message like memory_hotplug unless user
specifiy __GFP_NOWARN.
Signed-off-by: Minchan Kim
---
mm/page_alloc.c | 16 +++-
1 file changed, 15
On Tue, Feb 16, 2021 at 06:22:42PM +, Matthew Wilcox wrote:
> On Tue, Feb 16, 2021 at 09:03:47AM -0800, Minchan Kim wrote:
> > LRU pagevec holds refcount of pages until the pagevec are drained.
> > It could prevent migration since the refcount of the page is greater
> &g
being cached in the LRU caches,
until migration has finished.
Signed-off-by: Chris Goldsworthy
Signed-off-by: Minchan Kim
---
fs/buffer.c | 13 +++--
include/linux/buffer_head.h | 2 ++
mm/swap.c | 5 -
3 files changed, 17 insertions(+), 3 deletions
-mm/c083b0ab6e410e33ca880d639f90ef4f6f3b33ff.1613020616.git.cgold...@codeaurora.org/
Signed-off-by: Minchan Kim
---
include/linux/migrate.h | 3 +++
mm/mempolicy.c | 6 +
mm/migrate.c| 55 ++---
mm/page_alloc.c | 3 +++
mm/swa
On Thu, Feb 11, 2021 at 11:39:05AM -0800, Chris Goldsworthy wrote:
> On 2021-02-11 06:09, Matthew Wilcox wrote:
> > On Wed, Feb 10, 2021 at 09:35:40PM -0800, Chris Goldsworthy wrote:
> > > +/* These are used to control the BH LRU invalidation during page
> > > migration */
> > > +static struct
se.
>
> Correspondingly, invalidate the BH LRU caches before a migration
> starts and stop any buffer_head from being cached in the LRU caches,
> until migration has finished.
>
> Signed-off-by: Chris Goldsworthy
> Cc: Minchan Kim
> Cc: Matthew Wilcox
> Cc: Andre
][ T460] el0_svc_common+0x9c/0x168
[ 1233.993360][ T460] do_el0_svc+0x1c/0x28
[ 1233.997358][ T460] el0_sync_handler+0xd8/0x250
[ 1234.001989][ T460] el0_sync+0x148/0x180
Signed-off-by: Minchan Kim
---
* from v1 -
https://lore.kernel.org/lkml/20210210162632.3903128-1-minc...@kernel.org
On Wed, Feb 10, 2021 at 06:14:46PM -0800, John Stultz wrote:
> On Wed, Feb 10, 2021 at 3:17 PM Minchan Kim wrote:
> >
> > On Wed, Feb 10, 2021 at 01:40:02PM -0800, John Stultz wrote:
> > > On Wed, Feb 10, 2021 at 9:48 AM Minchan Kim wrote:
> > > >
> > &g
On Wed, Feb 10, 2021 at 01:40:02PM -0800, John Stultz wrote:
> On Wed, Feb 10, 2021 at 9:48 AM Minchan Kim wrote:
> >
> > On Wed, Feb 10, 2021 at 09:32:09AM -0800, John Stultz wrote:
> > > On Wed, Feb 10, 2021 at 8:26 AM Minchan Kim wrote:
> > > >
>
On Wed, Feb 10, 2021 at 09:32:09AM -0800, John Stultz wrote:
> On Wed, Feb 10, 2021 at 8:26 AM Minchan Kim wrote:
> >
> > Linux VM is not hard to support PAGE_ALLOC_COSTLY_ODER allocation
> > so normally expects driver passes __GFP_NOWARN in that case
> > i
On Wed, Feb 10, 2021 at 09:24:52AM -0800, Suren Baghdasaryan wrote:
> The code looks fine to me. Description needs a bit polishing :)
>
> On Wed, Feb 10, 2021 at 8:26 AM Minchan Kim wrote:
> >
> > Linux VM is not hard to support PAGE_ALLOC_COSTLY_ODER allocation
> >
-off-by: Minchan Kim
---
drivers/dma-buf/heaps/system_heap.c | 9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 29e49ac17251..33c25a5e06f9 100644
--- a/drivers/dma-buf/heaps/system_heap.c
putback_lru_pages to put_page[1].
This patch removes it.
[1] c6c919eb90e0, ("mm: use put_page() to free page instead of
putback_lru_page()"
Reviewed-by: Oscar Salvador
Acked-by: Vlastimil Babka
Acked-by: Michal Hocko
Signed-off-by: Minchan Kim
---
* From v1 -
https://lore.kernel.or
me page migration used putback_lru_page() to release the
> migration source page. This would put the page on lru pvec even if it was in
> fact not mapped anywhere anymore, and only the drain would actually free it.
> Seems Minchan optimized this in 2016 by c6c919eb90e0 ("mm: use put_page() t
On Wed, Feb 10, 2021 at 12:05:48AM -0800, John Hubbard wrote:
> On 2/9/21 11:55 PM, Minchan Kim wrote:
> > Since CMA is getting used more widely, it's more important to
> > keep monitoring CMA statistics for system health since it's
> > directly related to user experience
/mm/cma/BLUETOOTH/cma_alloc_pages_[attempts|fails]
Signed-off-by: Minchan Kim
---
>From v2 -
>https://lore.kernel.org/linux-mm/20210208180142.2765456-1-minc...@kernel.org/
* sysfs doc and description modification - jhubbard
>From v1 -
>https://lore.kernel.org/linux-mm/202102031550
On Wed, Feb 10, 2021 at 07:43:37AM +0100, Greg KH wrote:
> On Tue, Feb 09, 2021 at 01:13:17PM -0800, Minchan Kim wrote:
> > On Tue, Feb 09, 2021 at 12:11:20PM -0800, John Hubbard wrote:
> > > On 2/9/21 9:49 AM, Greg KH wrote:
> > > > > > That's fine if you
On Tue, Feb 09, 2021 at 12:11:20PM -0800, John Hubbard wrote:
> On 2/9/21 9:49 AM, Greg KH wrote:
> > > > That's fine if you want to add it to the parent. If so, then the
> > > > kobject controls the lifetime of the structure, nothing else can.
> > >
> > > The problem was parent object(i.e.,
__alloc_contig_migrate_range already has lru_add_drain_all call
via migrate_prep. It's necessary to move LRU taget pages into
LRU list to be able to isolated. However, lru_add_drain_all call
after __alloc_contig_migrate_range is called is pointless.
This patch removes it.
Signed-off-by: Minchan
On Tue, Feb 09, 2021 at 04:24:14PM +0200, Georgi Djakov wrote:
> From: Patrick Daly
>
> Print the name of the CMA region for convenience. This is useful
> information to have when cma_alloc() fails.
>
> Signed-off-by: Patrick Daly
> Signed-off-by: Georgi Djakov
Acked-by: Minchan Kim
d wrote:
> > > > > On 2/8/21 3:36 PM, Minchan Kim wrote:
> > > > > ...
> > > > > > > > char name[CMA_MAX_NAME];
> > > > > > > > +#ifdef CONFIG_CMA_SYSFS
> > > > > > > > + struct cma_s
On Mon, Feb 08, 2021 at 05:57:17PM -0800, John Hubbard wrote:
> On 2/8/21 3:36 PM, Minchan Kim wrote:
> ...
> > > > char name[CMA_MAX_NAME];
> > > > +#ifdef CONFIG_CMA_SYSFS
> > > > + struct cma_stat *stat;
> > >
> > >
On Mon, Feb 08, 2021 at 01:34:06PM -0800, John Hubbard wrote:
> On 2/8/21 10:01 AM, Minchan Kim wrote:
> > Since CMA is getting used more widely, it's more important to
> > keep monitoring CMA statistics for system health since it's
> > directly related to user experience
/mm/cma/BLUETOOTH/cma_alloc_pages_[attempt|fail]
Signed-off-by: Minchan Kim
---
>From v1 -
>https://lore.kernel.org/linux-mm/20210203155001.4121868-1-minc...@kernel.org/
* fix sysfs build and refactoring - willy
* rename and drop some attributes - jhubbard
Documentation/ABI/testing
On Fri, Feb 05, 2021 at 01:58:06PM -0800, John Hubbard wrote:
> On 2/5/21 1:52 PM, Suren Baghdasaryan wrote:
> > > > > I takes your suggestion something like this.
> > > > >
> > > > > [alloc_range] could be order or range by interval
> > > > >
> > > > >
On Thu, Feb 04, 2021 at 10:41:14PM -0800, John Hubbard wrote:
> On 2/4/21 10:24 PM, Minchan Kim wrote:
> > On Thu, Feb 04, 2021 at 09:49:54PM -0800, John Hubbard wrote:
> > > On 2/4/21 9:17 PM, Minchan Kim wrote:
> ...
> > > # cat vmstat | grep -i cma
> > >
On Fri, Feb 05, 2021 at 12:12:17PM +, Matthew Wilcox wrote:
> On Thu, Feb 04, 2021 at 09:22:18PM -0800, Minchan Kim wrote:
> > > > + for (i = 0; i < cma_area_count; i++) {
> > > > + cma = _areas[i];
> > > > +
On Fri, Feb 05, 2021 at 12:25:52PM -0800, John Hubbard wrote:
> On 2/5/21 8:15 AM, Minchan Kim wrote:
> ...
> > > Yes, approximately. I was wondering if this would suffice at least as a
> > > baseline:
> > >
> > > cma_alloc_success 125
> > &
On Thu, Feb 04, 2021 at 09:49:54PM -0800, John Hubbard wrote:
> On 2/4/21 9:17 PM, Minchan Kim wrote:
> ...
> > > > > Presumably, having the source code, you can easily deduce that a
> > > > > bluetooth
> > > > > allocation failu
On Fri, Feb 05, 2021 at 02:55:26AM +, Matthew Wilcox wrote:
> On Wed, Feb 03, 2021 at 07:50:01AM -0800, Minchan Kim wrote:
> > +++ b/mm/Makefile
> > @@ -106,6 +106,7 @@ obj-$(CONFIG_ZSMALLOC) += zsmalloc.o
> > obj-$(CONFIG_Z3FOLD) += z3fold.o
> > obj-$(C
On Thu, Feb 04, 2021 at 06:52:01PM -0800, John Hubbard wrote:
> On 2/4/21 5:44 PM, Minchan Kim wrote:
> > On Thu, Feb 04, 2021 at 04:24:20PM -0800, John Hubbard wrote:
> > > On 2/4/21 4:12 PM, Minchan Kim wrote:
> > > ...
> > > > > &g
On Thu, Feb 04, 2021 at 04:24:20PM -0800, John Hubbard wrote:
> On 2/4/21 4:12 PM, Minchan Kim wrote:
> ...
> > > > Then, how to know how often CMA API failed?
> > >
> > > Why would you even need to know that, *in addition* to knowing specific
> > &g
On Thu, Feb 04, 2021 at 03:14:56PM -0800, John Hubbard wrote:
> On 2/4/21 12:07 PM, Minchan Kim wrote:
> > On Thu, Feb 04, 2021 at 12:50:58AM -0800, John Hubbard wrote:
> > > On 2/3/21 7:50 AM, Minchan Kim wrote:
> > > > Since CMA is getting used more widely, it's
On Thu, Feb 04, 2021 at 12:50:58AM -0800, John Hubbard wrote:
> On 2/3/21 7:50 AM, Minchan Kim wrote:
> > Since CMA is getting used more widely, it's more important to
> > keep monitoring CMA statistics for system health since it's
> > directly related to user experience
being cached in the LRU, until migration has
> finished.
Thanks for the work, Chris. I have a few of comments below.
>
> Signed-off-by: Chris Goldsworthy
> Cc: Minchan Kim
> Cc: Matthew Wilcox
> ---
> fs/buffer.c | 6 ++
> include/linux/buffer_head.h
allocation attempts
* the number of CMA allocation failures
* the number of CMA page allocation attempts
* the number of CMA page allocation failures
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-kernel-mm-cma | 39 +
include/linux/cma.h | 1 +
mm
devel/2018-October/127519.html
> (sorry, could not find lore links for these discussions)
>
> Suggested-by: Laura Abbott
> Signed-off-by: Suren Baghdasaryan
Reviewed-by: Minchan Kim
A note: This patch makes dmabuf system heap accounted as PSS so
if someone has relies on the size, the
On Tue, Feb 02, 2021 at 04:31:33PM -0800, Suren Baghdasaryan wrote:
> Replace BUG_ON(vma->vm_flags & VM_PFNMAP) in vm_insert_page with
> WARN_ON_ONCE and returning an error. This is to ensure users of the
> vm_insert_page that set VM_PFNMAP are notified of the wrong flag usage
> and get an
ring-buffer.
>
> For example, on a systems using zram as swap, we are more likely to
> see any page allocation errors preceding the swap write errors if the
> alerts are ratelimited.
>
> Signed-off-by: Georgi Djakov
Acked-by: Minchan Kim
On Thu, Jan 28, 2021 at 09:52:59AM -0800, Suren Baghdasaryan wrote:
> On Thu, Jan 28, 2021 at 1:13 AM Christoph Hellwig wrote:
> >
> > On Thu, Jan 28, 2021 at 12:38:17AM -0800, Suren Baghdasaryan wrote:
> > > Currently system heap maps its buffers with VM_PFNMAP flag using
> > > remap_pfn_range.
On Thu, Jan 28, 2021 at 12:28:37AM -0800, Chris Goldsworthy wrote:
> On 2021-01-26 18:59, Matthew Wilcox wrote:
> > On Tue, Jan 26, 2021 at 02:59:17PM -0800, Minchan Kim wrote:
> > > The release buffer_head in LRU is great improvement for migration
> > > point of vi
On Thu, Jan 28, 2021 at 08:53:25AM +0100, Michal Hocko wrote:
> On Wed 27-01-21 12:42:45, Minchan Kim wrote:
> > On Tue, Jan 26, 2021 at 08:44:49AM +0100, Michal Hocko wrote:
> > > On Mon 25-01-21 11:33:36, Minchan Kim wrote:
> > > > On Mon, Jan 25, 2021 at 02:12:
On Tue, Jan 26, 2021 at 08:44:49AM +0100, Michal Hocko wrote:
> On Mon 25-01-21 11:33:36, Minchan Kim wrote:
> > On Mon, Jan 25, 2021 at 02:12:00PM +0100, Michal Hocko wrote:
> > > On Thu 21-01-21 09:55:00, Minchan Kim wrote:
> > > > Contiguous memory allocation
On Tue, Jan 26, 2021 at 11:12:14AM -0800, Minchan Kim wrote:
> On Tue, Jan 26, 2021 at 08:38:08AM +0100, Michal Hocko wrote:
> > On Mon 25-01-21 11:42:34, Minchan Kim wrote:
> > > On Mon, Jan 25, 2021 at 02:07:01PM +0100, Michal Hocko wrote:
> > > > On Thu 21-01-
On Wed, Jan 27, 2021 at 02:59:22AM +, Matthew Wilcox wrote:
> On Tue, Jan 26, 2021 at 02:59:17PM -0800, Minchan Kim wrote:
> > The release buffer_head in LRU is great improvement for migration
> > point of view.
> >
> > A question:
> >
> > Can't
On Mon, Jan 25, 2021 at 10:58:30PM -0800, Chris Goldsworthy wrote:
> From: Laura Abbott
>
> When a buffer is added to the LRU list, a reference is taken which is
> not dropped until the buffer is evicted from the LRU list. This is the
> correct behavior, however this LRU reference will prevent
On Tue, Jan 26, 2021 at 07:07:44AM +, Christoph Hellwig wrote:
> > +config DMABUF_HEAPS_CHUNK
> > + bool "DMA-BUF CHUNK Heap"
> > + depends on DMABUF_HEAPS && DMA_CMA
> > + help
> > + Choose this option to enable dma-buf CHUNK heap. This heap is backed
> > + by the Contiguous
On Tue, Jan 26, 2021 at 08:46:05AM +0100, Michal Hocko wrote:
> On Thu 21-01-21 09:55:02, Minchan Kim wrote:
> > From: Hyesoo Yu
> >
> > This patch supports chunk heap that allocates the buffers that
> > arranged into a list a fixed size chunks taken from CMA.
>
On Mon, Jan 25, 2021 at 11:32:57PM -0800, John Stultz wrote:
> On Thu, Jan 21, 2021 at 9:55 AM Minchan Kim wrote:
>
> Hey Minchan,
> Thanks for sending this out! I'm still working through testing with
> this patch set, so I may have some more feedback tomorrow, but a few
>
On Tue, Jan 26, 2021 at 08:38:08AM +0100, Michal Hocko wrote:
> On Mon 25-01-21 11:42:34, Minchan Kim wrote:
> > On Mon, Jan 25, 2021 at 02:07:01PM +0100, Michal Hocko wrote:
> > > On Thu 21-01-21 09:54:59, Minchan Kim wrote:
> > > > The upcoming patch will in
On Tue, Jan 26, 2021 at 08:44:49AM +0100, Michal Hocko wrote:
> On Mon 25-01-21 11:33:36, Minchan Kim wrote:
> > On Mon, Jan 25, 2021 at 02:12:00PM +0100, Michal Hocko wrote:
> > > On Thu 21-01-21 09:55:00, Minchan Kim wrote:
> > > > Contiguous memory allocation
On Mon, Jan 25, 2021 at 02:12:00PM +0100, Michal Hocko wrote:
> On Thu 21-01-21 09:55:00, Minchan Kim wrote:
> > Contiguous memory allocation can be stalled due to waiting
> > on page writeback and/or page lock which causes unpredictable
> > delay. It's a unavoidable cost for
On Mon, Jan 25, 2021 at 02:07:01PM +0100, Michal Hocko wrote:
> On Thu 21-01-21 09:54:59, Minchan Kim wrote:
> > The upcoming patch will introduce __GFP_NORETRY semantic
> > in alloc_contig_range which is a failfast mode of the API.
> > Instead of adding a additional param
On Mon, Jan 18, 2021 at 03:26:42PM +0530, vji...@codeaurora.org wrote:
> From: Vijayanand Jitta
>
> Add a kernel parameter stack_depot_disable to disable
> stack depot. So that stack hash table doesn't consume
> any memory when stack depot is disabled.
The usecase is CONFIG_PAGE_OWNER without
k Menon
> Signed-off-by: Vijayanand Jitta
Reviewed-by: Minchan Kim
On Thu, Jan 21, 2021 at 09:54:59AM -0800, Minchan Kim wrote:
> The upcoming patch will introduce __GFP_NORETRY semantic
> in alloc_contig_range which is a failfast mode of the API.
> Instead of adding a additional parameter for gfp, replace
> no_warn with gfp flag.
>
> To
dma-buf: heaps: add chunk heap to dmabuf heaps
Minchan Kim (2):
mm: cma: introduce gfp flag in cma_alloc instead of no_warn
mm: failfast mode with __GFP_NORETRY in alloc_contig_range
.../reserved-memory/dma_heap_chunk.yaml | 56 ++
drivers/dma-buf/heaps/Kconfig | 8 +
d
false GFP_KERNEL
true GFP_KERNEL|__GFP_NOWARN
gfp & __GFP_NOWARNGFP_KERNEL | (gfp & __GFP_NOWARN)
Reviewed-by: Suren Baghdasaryan
Signed-off-by: Minchan Kim
---
drivers/dma-buf/heaps/cma_heap.c | 2 +-
drivers/s390/cha
the request
in different range where would have easy migratable pages
without stalling.
This patch introduce __GFP_NORETRY as compaction gfp_mask in
alloc_contig_range so it will fail fast without blocking
when it encounters pages needed waiting.
Signed-off-by: Minchan Kim
---
mm/page_alloc.c | 8
/20191025225009.50305-2-john.stu...@linaro.org/T/#m3dc63acd33fea269a584f43bb799a876f0b2b45d
Reviewed-by: Suren Baghdasaryan
Signed-off-by: Hyesoo Yu
Signed-off-by: Hridya Valsaraju
Signed-off-by: Minchan Kim
---
drivers/dma-buf/heaps/Kconfig | 8 +
drivers/dma-buf/heaps/Makefile | 1 +
drivers
the user-space, there is no other appropriate device-driver that
we can use to register the chunk CMA heap and configure the reserved
memory region for its use.
Signed-off-by: Hyesoo Yu
Signed-off-by: Minchan Kim
Signed-off-by: Hridya Valsaraju
---
.../reserved-memory/dma_heap_chunk.yaml
On Tue, Jan 19, 2021 at 10:29:29AM -0800, John Stultz wrote:
> On Tue, Jan 12, 2021 at 5:22 PM Minchan Kim wrote:
> >
> > From: Hyesoo Yu
> >
> > This patch supports chunk heap that allocates the buffers that
> > arranged into a list a fixed size chunks taken
On Tue, Jan 12, 2021 at 05:21:43PM -0800, Minchan Kim wrote:
> From: Hyesoo Yu
>
> This patch supports chunk heap that allocates the buffers that
> arranged into a list a fixed size chunks taken from CMA.
>
> The chunk heap driver is bound directly to a reserved_memory
>
On Wed, Jan 13, 2021 at 09:39:26AM +0100, David Hildenbrand wrote:
> On 13.01.21 02:21, Minchan Kim wrote:
> > Contiguous memory allocation can be stalled due to waiting
> > on page writeback and/or page lock which causes unpredictable
> > delay. It's a unavoidable cost for
On Wed, Jan 13, 2021 at 11:11:56AM +0800, kernel test robot wrote:
> Hi Minchan,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on next-20210112]
> [cannot apply to s390/features robh/for-next linux/master linus/master
> hnaz-linu
On Tue, Jan 12, 2021 at 07:38:40PM -0800, Randy Dunlap wrote:
> On 1/12/21 5:21 PM, Minchan Kim wrote:
> > +config DMABUF_HEAPS_CHUNK
> > + bool "DMA-BUF CHUNK Heap"
> > + depends on DMABUF_HEAPS && DMA_CMA
> > + help
> > + Choose
From: Hyesoo Yu
Document devicetree binding for chunk cma heap on dma heap framework.
The DMA chunk heap supports the bulk allocation of higher order pages.
Signed-off-by: Hyesoo Yu
Signed-off-by: Minchan Kim
Signed-off-by: Hridya Valsaraju
Change-Id
/20191025225009.50305-2-john.stu...@linaro.org/T/#m3dc63acd33fea269a584f43bb799a876f0b2b45d
Signed-off-by: Hyesoo Yu
Signed-off-by: Hridya Valsaraju
Signed-off-by: Minchan Kim
---
drivers/dma-buf/heaps/Kconfig | 8 +
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/chunk_heap.c | 477
the request
in diffrent range where would have easy migratable pages
without stalling.
This patch introduce __GFP_NORETRY as compaction gfp_mask in
alloc_contig_range so it will fail fast without blocking
when it encounters pages needed waitting.
Signed-off-by: Minchan Kim
---
mm/page_alloc.c | 8
MA-BUF CMA heap DT-configurable
dma-buf: heaps: add chunk heap to dmabuf heaps
Minchan Kim (2):
mm: cma: introduce gfp flag in cma_alloc instead of no_warn
mm: failfast mode with __GFP_NORETRY in alloc_contig_range
.../reserved-memory/dma_heap_chunk.yaml | 58 +++
drivers/dma-buf/hea
false GFP_KERNEL
true GFP_KERNEL|__GFP_NOWARN
gfp & __GFP_NOWARNGFP_KERNEL | (gfp & __GFP_NOWARN)
Signed-off-by: Minchan Kim
---
drivers/dma-buf/heaps/cma_heap.c | 2 +-
drivers/s390/char/vmcp.c | 2 +-
include/lin
y folks don't see any concern and fix below,
Acked-by: Minchan Kim
> @@ -1197,12 +1197,22 @@ SYSCALL_DEFINE5(process_madvise, int, pidfd, const
> struct iovec __user *, vec,
> goto release_task;
> }
>
> - mm = mm_access(task, PTRACE_MODE_ATTACH_FSCREDS
would work for both these use cases,
> > >>> we can set it to '0' for first case and set the required size for the
> > >>> second case.
> > >>
> > >> Will a combined solution with a boolean boot-time flag and a static
> > >> CONFIG_STACKDE
On Mon, Dec 21, 2020 at 08:20:26PM +0100, Vitaly Wool wrote:
> On Mon, Dec 21, 2020 at 6:24 PM Minchan Kim wrote:
> >
> > On Sun, Dec 20, 2020 at 02:22:28AM +0200, Vitaly Wool wrote:
> > > zsmalloc takes bit spinlock in its _map() callback and releases it
> > >
On Sun, Dec 20, 2020 at 02:22:28AM +0200, Vitaly Wool wrote:
> zsmalloc takes bit spinlock in its _map() callback and releases it
> only in unmap() which is unsafe and leads to zswap complaining
> about scheduling in atomic context.
>
> To fix that and to improve RT properties of zsmalloc, remove
On Sat, Dec 12, 2020 at 11:26:25AM +0800, Alex Shi wrote:
> coccinelle reports some warning:
> WARNING: Use BUG_ON instead of if condition followed by BUG.
>
> It could be fixed by BUG_ON().
>
> Reported-by: ab...@linux.alibaba.com
> Signed-off-by: Alex Shi
Acked-by: Minchan Kim
Thanks.
On Fri, Dec 11, 2020 at 09:27:46PM +0100, Jann Horn wrote:
> +CC Christoph Hellwig for opinions on compat
>
> On Thu, Nov 26, 2020 at 12:22 AM Minchan Kim wrote:
> > On Mon, Nov 23, 2020 at 09:39:42PM -0800, Suren Baghdasaryan wrote:
> > > process_madvise requires a
On Thu, Dec 10, 2020 at 02:40:38PM -0800, John Stultz wrote:
> On Thu, Dec 10, 2020 at 8:06 AM Minchan Kim wrote:
> > On Thu, Dec 10, 2020 at 12:15:15AM -0800, John Stultz wrote:
> > > Well, while I agree that conceptually the dmabuf heaps allow for
> > > allocations
On Thu, Dec 10, 2020 at 12:15:15AM -0800, John Stultz wrote:
> On Wed, Dec 9, 2020 at 3:53 PM Minchan Kim wrote:
> > On Wed, Nov 18, 2020 at 07:19:07PM -0800, John Stultz wrote:
> > > The CMA heap currently only registers the default CMA heap, as we
> > > didn't wan
101 - 200 of 6935 matches
Mail list logo
