From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Doug Berger <opendmb@gmail.com>, Rob Herring <robh@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Frank Rowand <frowand.list@gmail.com>,
Mike Kravetz <mike.kravetz@oracle.com>,
Muchun Song <songmuchun@bytedance.com>,
Mike Rapoport <rppt@kernel.org>, Christoph Hellwig <hch@lst.de>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>, Borislav Petkov <bp@suse.de>,
"Paul E. McKenney" <paulmck@kernel.org>,
Neeraj Upadhyay <quic_neeraju@quicinc.com>,
Randy Dunlap <rdunlap@infradead.org>,
Damien Le Moal <damien.lemoal@opensource.wdc.com>,
Florian Fainelli <f.fainelli@gmail.com>,
David Hildenbrand <david@redhat.com>, Zi Yan <ziy@nvidia.com>,
Oscar Salvador <osalvador@suse.de>,
Hari Bathini <hbathini@linux.ibm.com>,
Kees Cook <keescook@chromium.org>,
- <devicetree-spec@vger.kernel.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Mel Gorman <mgorman@suse.de>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-mm@kvack.org,
iommu@lists.linux.dev
Subject: Re: [PATCH 16/21] dt-bindings: reserved-memory: introduce designated-movable-block
Date: Wed, 21 Sep 2022 08:35:43 +0200 [thread overview]
Message-ID: <12602c20-d653-4d64-8589-b33270e2baa2@linaro.org> (raw)
In-Reply-To: <92a2cf9f-c371-fb7d-11ff-90cdc09dcae6@gmail.com>
On 21/09/2022 02:14, Doug Berger wrote:
> On 9/19/2022 4:03 AM, Krzysztof Kozlowski wrote:
>> On 19/09/2022 01:12, Doug Berger wrote:
>>> On 9/18/2022 3:31 AM, Krzysztof Kozlowski wrote:
>>>> On 14/09/2022 18:13, Doug Berger wrote:
>>>>> On 9/14/2022 7:55 AM, Rob Herring wrote:
>>>>>> On Tue, Sep 13, 2022 at 12:55:03PM -0700, Doug Berger wrote:
>>>>>>> Introduce designated-movable-block.yaml to document the
>>>>>>> devicetree binding for Designated Movable Block children of the
>>>>>>> reserved-memory node.
>>>>>>
>>>>>> What is a Designated Movable Block? This patch needs to stand on its
>>>>>> own.
>>>>> As noted in my reply to your [PATCH 00/21] comment, my intention in
>>>>> submitting the entire patch set (and specifically PATCH 00/21]) was to
>>>>> communicate this context. Now that I believe I understand that only this
>>>>> patch should have been submitted to the devicetree-spec mailing list, I
>>>>> will strive harder to make it more self contained.
>>>>
>>>> The submission of entire thread was ok. What is missing is the
>>>> explanation in this commit. This commit must be self-explanatory (e.g.
>>>> in explaining "Why are you doing it?"), not rely on other commits for
>>>> such explanation.
>>>>
>>>>>
>>>>>>
>>>>>> Why does this belong or need to be in DT?
>>>>> While my preferred method of declaring Designated Movable Blocks is
>>>>> through the movablecore kernel parameter, I can conceive that others may
>>>>> wish to take advantage of the reserved-memory DT nodes. In particular,
>>>>> it has the advantage that a device can claim ownership of the
>>>>> reserved-memory via device tree, which is something that has yet to be
>>>>> implemented for DMBs defined with movablecore.
>>>>
>>>> Rephrasing the question: why OS memory layout and OS behavior is a
>>>> property of hardware (DTS)?
>>> I would say the premise is fundamentally the same as the existing
>>> reserved-memory child node.
>>
>> I don't think it is fundamentally the same.
>>
>> The existing reserved-memory node describes memory used by hardware - by
>> other devices. The OS way of handling this memory - movable, reclaimable
>> etc - is not part of it.
>>
>> So no, it is not the same.
>>
>>>
>>> I've been rethinking how this should be specified. I am now thinking
>>> that it may be better to introduce a new Reserved Memory property that
>>> serves as a modifier to the 'reusable' property. The 'reusable' property
>>> allows the OS to use memory that has been reserved for a device and
>>> therefore requires the device driver to reclaim the memory prior to its
>>> use. However, an OS may have multiple ways of implementing such reuse
>>> and reclamation.
>>
>> ... and I repeat the question - why OS way of implementing reuse and
>> reclamation is relevant to DT?
>>
>>> I am considering introducing the vendor specific 'linux,dmb' property
>>> that is dependent on the 'reusable' property to allow both the OS and
>>> the device driver to identify the method used by the Linux OS to support
>>> reuse and reclamation of the reserved-memory child node.
>>
>> Sure, but why? Why OS and Linux driver specific pieces should be in DT?
>>> Such a property would remove any need for new compatible strings to the
>>> device tree. Does that approach seem reasonable to you?
>>
>> No, because you did not explain original question. At all.
> I apologize if I have somehow offended you, but please recognize that my
> apparent inability to answer your question does not come from an
> unwillingness to do so.
>
> I believe an example of the reserved-memory node being used the way you
> indicate (though there are other uses) can be expressed with device tree
> nodes like these:
>
> reserved-memory {
> #address-cells = <0x1>;
> #size-cells = <0x1>;
> ranges;
>
> multimedia_reserved: multimedia@80000000 {
> reg = <0x80000000 0x10000000>;
> };
> };
>
> decoder@8012000 {
> memory-region = <&multimedia_reserved>;
> /* ... */
> };
>
> Here a 256MB chunk of memory is reserved for use by a hardware decoder
> as part of rendering a video stream. In this case the memory is reserved
> for the exclusive use of the decoder device and its associated device
> driver.
>
> The Devicetree Specification includes a property named 'reusable' that
> could be applied to the multimedia node to allow the OS to "use the
> memory in this region with the limitation that the device driver(s)
> owning the region need to be able to reclaim it back".
Indeed, there is such.... and should be used instead. :)
> This is a good
> idea, because this memory could probably be put to good use when the
> decoder is not active. Unfortunately, the methods for reusing this
> memory are not defined for Linux so the multimedia reserved memory would
> not be reused even though the devicetree indicates that it is allowed.
Then rather implementation has to be changed, not Devicetree bindings.
>
> The notion behind this commit was to introduce the
> 'designated-movable-block' compatible string that could be added to the
> multimedia node to allow the Client Program (i.e. Linux) to select a
> device driver that knows how to reclaim reserved memory back from the OS
> when it is needed by the decoder device and release it back to the OS
> when the decoder no longer needs it. In this way, the purpose of the
> multimedia node remains the same (i.e. to reserve memory for use by a
> device), but a new compatible string is defined to allow for selection
> of an appropriate device driver and allow successful reuse of the memory
> for the benefit of the system.
We don't need a new compatible for it but use that existing property.
>
> From Rob's feedback it is clear that 'designated-movable-block' is not
> an appropriate name, but maybe 'linux,dmb' might have been. However, it
> would be more flexible if a 'linux,dmb' property could be introduced as
> a modifier to the existing 'reusable' property to provide a general
> mechanism for clarifying how 'reusable' should be supported by the
> Client Software and its device drivers.
>
> Such a property is not directly relevant to hardware, but the devicetree
> is not wholly concerned with hardware. Reserved memory node children
> include support for 'linux,cma-default' and 'linux,dma-default'
> properties that signal behavioral intent to the Linux OS. Some aspects
> of the devicetree (e.g. the /chosen node and 'reusable' property) are
> for the benefit of the Client Program.
Fair enough, although there is difference between generic property for
reusable/reclaimable memory and a property describing one of Linux
memory-management zones.
Best regards,
Krzysztof
next prev parent reply other threads:[~2022-09-21 6:35 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-13 19:54 [PATCH 00/21] mm: introduce Designated Movable Blocks Doug Berger
2022-09-13 19:54 ` [PATCH 01/21] mm/page_isolation: protect cma from isolate_single_pageblock Doug Berger
2022-09-14 0:02 ` Zi Yan
2022-09-14 0:59 ` Doug Berger
2022-09-14 1:09 ` Zi Yan
2022-09-14 1:47 ` Doug Berger
2022-09-14 1:53 ` Zi Yan
2022-09-14 17:27 ` Doug Berger
2022-09-16 3:40 ` kernel test robot
2022-09-13 19:54 ` [PATCH 02/21] mm/hugetlb: correct max_huge_pages accounting on demote Doug Berger
2022-09-14 17:23 ` Mike Kravetz
2022-09-14 17:26 ` Florian Fainelli
2022-09-14 18:43 ` Mike Kravetz
2022-09-14 17:30 ` Doug Berger
2022-09-14 20:58 ` Andrew Morton
2022-09-14 21:11 ` Mike Kravetz
2022-09-13 19:54 ` [PATCH 03/21] mm/hugetlb: correct demote page offset logic Doug Berger
2022-09-13 23:34 ` Matthew Wilcox
2022-09-14 1:07 ` Doug Berger
2022-09-14 17:08 ` Mike Kravetz
2022-09-14 17:54 ` Doug Berger
2022-09-15 1:40 ` Muchun Song
2022-09-13 19:54 ` [PATCH 04/21] mm/hugetlb: refactor alloc_and_dissolve_huge_page Doug Berger
2022-09-13 19:54 ` [PATCH 05/21] mm/hugetlb: allow migrated hugepage to dissolve when freed Doug Berger
2022-09-13 19:54 ` [PATCH 06/21] mm/hugetlb: add hugepage isolation support Doug Berger
2022-09-13 19:54 ` [PATCH 07/21] lib/show_mem.c: display MovableOnly Doug Berger
2022-09-13 19:54 ` [PATCH 08/21] mm/vmstat: show start_pfn when zone spans pages Doug Berger
2022-09-13 19:54 ` [PATCH 09/21] mm/page_alloc: calculate node_spanned_pages from pfns Doug Berger
2022-09-13 19:54 ` [PATCH 10/21] mm/page_alloc.c: allow oversized movablecore Doug Berger
2022-09-13 19:54 ` [PATCH 11/21] mm/page_alloc: introduce init_reserved_pageblock() Doug Berger
2022-09-13 19:54 ` [PATCH 12/21] memblock: introduce MEMBLOCK_MOVABLE flag Doug Berger
2022-09-13 19:55 ` [PATCH 13/21] mm/dmb: Introduce Designated Movable Blocks Doug Berger
2022-09-13 19:55 ` [PATCH 14/21] mm/page_alloc: make alloc_contig_pages DMB aware Doug Berger
2022-09-13 19:55 ` [PATCH 15/21] mm/page_alloc: allow base for movablecore Doug Berger
2022-09-13 19:55 ` [PATCH 16/21] dt-bindings: reserved-memory: introduce designated-movable-block Doug Berger
2022-09-14 14:55 ` Rob Herring
2022-09-14 17:13 ` Doug Berger
2022-09-18 10:31 ` Krzysztof Kozlowski
2022-09-18 23:12 ` Doug Berger
2022-09-19 11:03 ` Krzysztof Kozlowski
2022-09-21 0:14 ` Doug Berger
2022-09-21 6:35 ` Krzysztof Kozlowski [this message]
2022-09-18 10:28 ` Krzysztof Kozlowski
2022-09-18 22:41 ` Doug Berger
2022-09-13 19:55 ` [PATCH 17/21] mm/dmb: introduce rmem designated-movable-block Doug Berger
2022-09-13 19:55 ` [PATCH 18/21] mm/cma: support CMA in Designated Movable Blocks Doug Berger
2022-09-14 17:07 ` kernel test robot
2022-09-14 17:58 ` kernel test robot
2022-09-14 22:03 ` kernel test robot
2022-09-13 19:55 ` [PATCH 19/21] dt-bindings: reserved-memory: shared-dma-pool: support DMB Doug Berger
2022-09-13 19:55 ` [PATCH 20/21] mm/cma: introduce rmem shared-dmb-pool Doug Berger
2022-09-13 19:55 ` [PATCH 21/21] mm/hugetlb: introduce hugetlb_dmb Doug Berger
2022-09-14 13:21 ` [PATCH 00/21] mm: introduce Designated Movable Blocks Rob Herring
2022-09-14 16:57 ` Doug Berger
2022-09-14 18:07 ` Rob Herring
2022-09-19 9:00 ` David Hildenbrand
2022-09-20 1:03 ` Doug Berger
2022-09-23 11:19 ` Mike Rapoport
2022-09-23 22:10 ` Doug Berger
2022-09-29 9:00 ` David Hildenbrand
2022-10-01 0:42 ` Doug Berger
2022-10-05 18:39 ` David Hildenbrand
2022-10-12 23:38 ` Doug Berger
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=12602c20-d653-4d64-8589-b33270e2baa2@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=bp@suse.de \
--cc=corbet@lwn.net \
--cc=damien.lemoal@opensource.wdc.com \
--cc=david@redhat.com \
--cc=devicetree-spec@vger.kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=frowand.list@gmail.com \
--cc=hbathini@linux.ibm.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=keescook@chromium.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=mgorman@suse.de \
--cc=mike.kravetz@oracle.com \
--cc=opendmb@gmail.com \
--cc=osalvador@suse.de \
--cc=paulmck@kernel.org \
--cc=quic_neeraju@quicinc.com \
--cc=rdunlap@infradead.org \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=songmuchun@bytedance.com \
--cc=ziy@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).