All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonsoo Kim <js1304@gmail.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	iommu@lists.linux-foundation.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Nazarewicz <mina86@mina86.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Vlastimil Babka <vbabka@suse.cz>, Christoph Hellwig <hch@lst.de>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Paul Mackerras <paulus@ozlabs.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Chris Zankel <chris@zankel.net>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Joerg Roedel <joro@8bytes.org>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Laura Abbott <labbott@redhat.com>,
	linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH 1/2] mm/cma: remove unsupported gfp_mask parameter from cma_alloc()
Date: Wed, 11 Jul 2018 16:35:28 +0900	[thread overview]
Message-ID: <CAAmzW4P1m_T77DfQzDD6ysGaOF46++-0gwRaOajmo6ef=VYp=A@mail.gmail.com> (raw)
In-Reply-To: <20180710095056.GE14284@dhcp22.suse.cz>

2018-07-10 18:50 GMT+09:00 Michal Hocko <mhocko@kernel.org>:
> On Tue 10-07-18 16:19:32, Joonsoo Kim wrote:
>> Hello, Marek.
>>
>> 2018-07-09 21:19 GMT+09:00 Marek Szyprowski <m.szyprowski@samsung.com>:
>> > cma_alloc() function doesn't really support gfp flags other than
>> > __GFP_NOWARN, so convert gfp_mask parameter to boolean no_warn parameter.
>>
>> 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 about GFP_NO{FS,IO}?

I don't know. My guess is that cma_alloc() is used for DMA allocation so
block device would use it, too. If fs/block subsystem initiates the
request for the device,
it would be possible that cma_alloc() is called with such a flag.
Again, I don't know
much about those subsystem so I would be wrong.

Thanks.

WARNING: multiple messages have this Message-ID (diff)
From: Joonsoo Kim <js1304@gmail.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	iommu@lists.linux-foundation.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Nazarewicz <mina86@mina86.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Vlastimil Babka <vbabka@suse.cz>, Christoph Hellwig <hch@lst.de>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Paul Mackerras <paulus@ozlabs.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Chris Zankel <chris@zankel.net>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Joerg Roedel <joro@8bytes.org>
Subject: Re: [PATCH 1/2] mm/cma: remove unsupported gfp_mask parameter from cma_alloc()
Date: Wed, 11 Jul 2018 16:35:28 +0900	[thread overview]
Message-ID: <CAAmzW4P1m_T77DfQzDD6ysGaOF46++-0gwRaOajmo6ef=VYp=A@mail.gmail.com> (raw)
In-Reply-To: <20180710095056.GE14284@dhcp22.suse.cz>

2018-07-10 18:50 GMT+09:00 Michal Hocko <mhocko@kernel.org>:
> On Tue 10-07-18 16:19:32, Joonsoo Kim wrote:
>> Hello, Marek.
>>
>> 2018-07-09 21:19 GMT+09:00 Marek Szyprowski <m.szyprowski@samsung.com>:
>> > cma_alloc() function doesn't really support gfp flags other than
>> > __GFP_NOWARN, so convert gfp_mask parameter to boolean no_warn parameter.
>>
>> 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 about GFP_NO{FS,IO}?

I don't know. My guess is that cma_alloc() is used for DMA allocation so
block device would use it, too. If fs/block subsystem initiates the
request for the device,
it would be possible that cma_alloc() is called with such a flag.
Again, I don't know
much about those subsystem so I would be wrong.

Thanks.

WARNING: multiple messages have this Message-ID (diff)
From: js1304@gmail.com (Joonsoo Kim)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] mm/cma: remove unsupported gfp_mask parameter from cma_alloc()
Date: Wed, 11 Jul 2018 16:35:28 +0900	[thread overview]
Message-ID: <CAAmzW4P1m_T77DfQzDD6ysGaOF46++-0gwRaOajmo6ef=VYp=A@mail.gmail.com> (raw)
In-Reply-To: <20180710095056.GE14284@dhcp22.suse.cz>

2018-07-10 18:50 GMT+09:00 Michal Hocko <mhocko@kernel.org>:
> On Tue 10-07-18 16:19:32, Joonsoo Kim wrote:
>> Hello, Marek.
>>
>> 2018-07-09 21:19 GMT+09:00 Marek Szyprowski <m.szyprowski@samsung.com>:
>> > cma_alloc() function doesn't really support gfp flags other than
>> > __GFP_NOWARN, so convert gfp_mask parameter to boolean no_warn parameter.
>>
>> 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 about GFP_NO{FS,IO}?

I don't know. My guess is that cma_alloc() is used for DMA allocation so
block device would use it, too. If fs/block subsystem initiates the
request for the device,
it would be possible that cma_alloc() is called with such a flag.
Again, I don't know
much about those subsystem so I would be wrong.

Thanks.

  reply	other threads:[~2018-07-11  7:35 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180709121956.20200-1-m.szyprowski@samsung.com>
     [not found] ` <CGME20180709122019eucas1p2340da484acfcc932537e6014f4fd2c29@eucas1p2.samsung.com>
2018-07-09 12:19   ` [PATCH 1/2] mm/cma: remove unsupported gfp_mask parameter from cma_alloc() Marek Szyprowski
2018-07-09 12:19     ` Marek Szyprowski
2018-07-09 12:19     ` Marek Szyprowski
2018-07-09 13:09     ` Michal Hocko
2018-07-09 13:09       ` Michal Hocko
2018-07-09 13:09       ` Michal Hocko
2018-07-09 14:23     ` Michał Nazarewicz
2018-07-09 14:23       ` Michał Nazarewicz
2018-07-09 17:27     ` Laura Abbott
2018-07-09 17:27       ` Laura Abbott
2018-07-09 17:27       ` Laura Abbott
2018-07-10  7:19     ` Joonsoo Kim
2018-07-10  7:19       ` Joonsoo Kim
2018-07-10  7:19       ` Joonsoo Kim
2018-07-10  9:50       ` Michal Hocko
2018-07-10  9:50         ` Michal Hocko
2018-07-10  9:50         ` Michal Hocko
2018-07-11  7:35         ` Joonsoo Kim [this message]
2018-07-11  7:35           ` Joonsoo Kim
2018-07-11  7:35           ` Joonsoo Kim
2018-07-11  8:54           ` Michal Hocko
2018-07-11  8:54             ` Michal Hocko
2018-07-11  8:54             ` Michal Hocko
2018-07-12  2:48             ` Joonsoo Kim
2018-07-12  2:48               ` Joonsoo Kim
2018-07-12  2:48               ` Joonsoo Kim
2018-07-12  7:15               ` Christoph Hellwig
2018-07-12  7:15                 ` Christoph Hellwig
2018-07-12  7:15                 ` Christoph Hellwig
2018-07-13  6:29                 ` Joonsoo Kim
2018-07-13  6:29                   ` Joonsoo Kim
2018-07-13  6:29                   ` Joonsoo Kim
2018-07-16  7:45     ` Vlastimil Babka
2018-07-16  7:45       ` Vlastimil Babka
2018-07-17 15:08     ` Christoph Hellwig
2018-07-17 15:08       ` Christoph Hellwig
2018-07-17 15:08       ` Christoph Hellwig
     [not found] ` <CGME20180709122020eucas1p21a71b092975cb4a3b9954ffc63f699d1@eucas1p2.samsung.com>
2018-07-09 12:19   ` [PATCH 2/2] dma: remove unsupported gfp_mask parameter from dma_alloc_from_contiguous() Marek Szyprowski
2018-07-09 12:19     ` Marek Szyprowski
2018-07-09 14:25     ` Michał Nazarewicz
2018-07-09 14:25       ` Michał Nazarewicz
2018-07-16  7:45     ` Vlastimil Babka
2018-07-16  7:45       ` Vlastimil Babka
2018-07-16  7:45       ` Vlastimil Babka
2018-07-17 15:08     ` Christoph Hellwig
2018-07-17 15:08       ` Christoph Hellwig
2018-07-17 15:08       ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAmzW4P1m_T77DfQzDD6ysGaOF46++-0gwRaOajmo6ef=VYp=A@mail.gmail.com' \
    --to=js1304@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=catalin.marinas@arm.com \
    --cc=chris@zankel.net \
    --cc=hch@lst.de \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=labbott@redhat.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mhocko@kernel.org \
    --cc=mina86@mina86.com \
    --cc=paulus@ozlabs.org \
    --cc=robin.murphy@arm.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=sumit.semwal@linaro.org \
    --cc=vbabka@suse.cz \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.