ry is below min watermark (node zone DMA has
lowmem protection for GFP_KERNEL allocation).
[...]
> [4.923156] Out of memory and no killable processes...
and there is no task existing to be killed so we go and panic.
--
Michal Hocko
SUSE Labs
s to be merged. We don't want slab caches with GFP_DMA32 and
> ~GFP_DMA32 to be merged, so it should be in there.
> (https://elixir.bootlin.com/linux/v4.19.6/source/mm/slab_common.c#L342).
Ohh, my bad, I have misread the change. Sure we definitely not want
is this
going to merge with?
--
Michal Hocko
SUSE Labs
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
estricted cache then allow allocating restricted memory from that.
Is there any fundamental reason that this wouldn't be possible?
--
Michal Hocko
SUSE Labs
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
V7S_TABLE_SLAB_CACHE SLAB_CACHE_DMA32
> > +#else
> > +#define ARM_V7S_TABLE_GFP_DMA GFP_DMA
> > +#define ARM_V7S_TABLE_SLAB_CACHE SLAB_CACHE_DMA
> > +#endif
>
> It's a bit grotty that GFP_DMA32 doesn't just map to GFP_DMA on 32-bit
> architectures,
On Wed 11-07-18 16:35:28, Joonsoo Kim wrote:
> 2018-07-10 18:50 GMT+09:00 Michal Hocko :
> > On Tue 10-07-18 16:19:32, Joonsoo Kim wrote:
> >> Hello, Marek.
> >>
> >> 2018-07-09 21:19 GMT+09:00 Marek Szyprowski :
> >> > cma_alloc() func
Although gfp_mask isn't used in cma_alloc() except no_warn, it can be used
> in alloc_contig_range(). For example, if passed gfp mask has no __GFP_FS,
> compaction(isolation) would work differently. Do you have considered
> such a case?
Does any of cma_alloc users actually care a
nse to me. If there is a real need for the
gfp_mask then we should start by defining the semantic first.
Acked-by: Michal Hocko
> ---
> arch/powerpc/kvm/book3s_hv_builtin.c | 2 +-
> drivers/s390/char/vmcp.c | 2 +-
> drivers/staging/android/ion/ion_cma_heap.c |
On Wed 30-05-18 09:02:13, Huaisheng HS1 Ye wrote:
> From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On Behalf Of
> Michal Hocko
> Sent: Monday, May 28, 2018 9:38 PM
> > > In my opinion, originally there shouldn't be such many wrong
> > > combinat
On Fri 25-05-18 09:43:09, Huaisheng HS1 Ye wrote:
> From: Michal Hocko [mailto:mho...@kernel.org]
> Sent: Thursday, May 24, 2018 8:19 PM>
> > > Let me try to reply your questions.
> > > Exactly, GFP_ZONE_TABLE is too complicated. I think there are two
> > >
On Fri 25-05-18 05:00:44, Matthew Wilcox wrote:
> On Thu, May 24, 2018 at 05:29:43PM +0200, Michal Hocko wrote:
> > > ie if we had more,
> > > could we solve our pain by making them more generic?
> >
> > Well, if you have more you will consume more bits in the
On Thu 24-05-18 08:18:18, Matthew Wilcox wrote:
> On Thu, May 24, 2018 at 02:23:23PM +0200, Michal Hocko wrote:
> > > If we had eight ZONEs, we could offer:
> >
> > No, please no more zones. What we have is quite a maint. burden on its
> > own. Ideally we should
On Wed 23-05-18 22:19:19, Matthew Wilcox wrote:
> On Tue, May 22, 2018 at 08:37:28PM +0200, Michal Hocko wrote:
> > So why is this any better than the current code. Sure I am not a great
> > fan of GFP_ZONE_TABLE because of how it is incomprehensible but this
> > doesn't
On Wed 23-05-18 16:07:16, Huaisheng HS1 Ye wrote:
> From: Michal Hocko [mailto:mho...@kernel.org]
> Sent: Wednesday, May 23, 2018 2:37 AM
> >
> > On Mon 21-05-18 23:20:21, Huaisheng Ye wrote:
> > > From: Huaisheng Ye
> > >
> > > Replace GFP_ZONE_TA
-
> include/linux/highmem.h | 4 +-
> mm/vmpressure.c | 2 +-
> mm/zsmalloc.c| 4 +-
> 12 files changed, 26 insertions(+), 103 deletions(-)
>
> --
> 1.8.3.1
>
--
Michal Hocko
SUSE Labs
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
ne of those really explain what the allocation
failure effect is. The allocation path already tells us about the
failure enough.
> Signed-off-by: Markus Elfring
Acked-by: Michal Hocko
> ---
> lib/test_kasan.c | 5 ++---
> lib/test_kmod.c | 8 ++--
> lib/test_lis
do not have any objections.
> Signed-off-by: Ganapatrao Kulkarni
Acked-by: Michal Hocko
> ---
> include/linux/gfp.h | 2 +-
> mm/page_alloc.c | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
>
the flag to the
> underlying alloc_contig_range function.
>
> Signed-off-by: Lucas Stach
Acked-by: Michal Hocko
> ---
> arch/powerpc/kvm/book3s_hv_builtin.c | 3 ++-
> drivers/base/dma-contiguous.c| 2 +-
> include/linux/cma.h | 3 ++-
> mm/cma.c
nt);
> diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
> index fec734df1524..b67bf6ac907d 100644
> --- a/include/linux/dma-contiguous.h
> +++ b/include/linux/dma-contiguous.h
> @@ -112,7 +112,7 @@ static inline int dma_declare_contiguous(struc
eries). Note
> that then it's technically a functional change, but it's needed.
> Otherwise looks good.
yes, with that added, feel free to add
Acked-by: Michal Hocko
>
> > };
> > INIT_LIST_HEAD(&cc.migratepages);
> >
> >
--
Michal
20 matches
Mail list logo
