Received-SPF: pass (google.com: domain of linux-kernel+bounces-201235-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Received-SPF: Pass (protection.outlook.com: domain of oppo.com designates
 58.252.5.68 as permitted sender) receiver=protection.outlook.com;
 client-ip=58.252.5.68; helo=mail.oppo.com; pr=C
Message-ID: <f6dcb031-9668-4387-b279-958e344bdbaf@oppo.com>
Date: Wed, 5 Jun 2024 02:16:50 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v1] dma-buf: heaps: move the verification of
 heap_flags to the corresponding heap
To: John Stultz <jstultz@google.com>
CC: Sumit Semwal <sumit.semwal@linaro.org>, Benjamin Gaignard
	<benjamin.gaignard@collabora.com>, Brian Starkey <Brian.Starkey@arm.com>,
	"T.J. Mercier" <tjmercier@google.com>, =?UTF-8?Q?Christian_K=C3=B6nig?=
	<christian.koenig@amd.com>, <21cnbao@gmail.com>,
	<linux-media@vger.kernel.org>, <dri-devel@lists.freedesktop.org>,
	<linaro-mm-sig@lists.linaro.org>, <linux-kernel@vger.kernel.org>
References: <20240603114008.16235-1-hailong.liu@oppo.com>
 <CANDhNCq50zPB+TS+_Oo0HY0aUuBAdik2KrC8eJRTygbis293sw@mail.gmail.com>
 <20240603172148.gb7txpg2ya43jyxn@oppo.com>
 <CANDhNCrwgce7G5_-4tNfgTHcdL12zt3JKBg=o3bHrzMmfFMctg@mail.gmail.com>
 <cff79c75-4c9c-46e0-a3ac-b9c0e8cad6f0@oppo.com>
 <CANDhNCq1O9T6WxCpe9yNBycMu7U0SCVYBdW3R=J8jEqyqWYCiA@mail.gmail.com>
Content-Language: en-US
From: Hailong Liu <hailong.liu@oppo.com>
In-Reply-To: <CANDhNCq1O9T6WxCpe9yNBycMu7U0SCVYBdW3R=J8jEqyqWYCiA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2024 18:16:57.0963
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a1e685c1-8e15-4058-48ef-08dc84c28535
X-MS-Exchange-CrossTenant-Id: f1905eb1-c353-41c5-9516-62b4a54b5ee6
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f1905eb1-c353-41c5-9516-62b4a54b5ee6;Ip=[58.252.5.68];Helo=[mail.oppo.com]
X-MS-Exchange-CrossTenant-AuthSource:
	HK3PEPF0000021E.apcprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SI2PR02MB5860

On 6/4/2024 11:33 PM, John Stultz wrote:
> On Mon, Jun 3, 2024 at 11:30 PM Hailong Liu <hailong.liu@oppo.com> wrote:
>> On 6/4/2024 2:06 AM, John Stultz wrote:
>>> On Mon, Jun 3, 2024 at 10:21 AM Hailong Liu <hailong.liu@oppo.com> wrote:
>>>> We now aim to improve priority dma-buf allocation. Consider android
>>>> animations scene:
>>>>
>>>> when device is in low memory, Allocating dma-buf as animation
>>>> buffers enter direct_reclaimation, longer allocation time result in a
>>>> laggy UI. But if we know the usage of the dma-buf, we can use some
>>>> mechanisms to boost, e.g. animation-memory-pool.
>>>
>>> Can you generalize this a bit further? When would userland know to use
>>> this new flag?
>>> If it is aware, would it make sense to just use a separate heap name instead?
>>>
>>> (Also: These other mechanisms you mention should probably also be
>>> submitted upstream, however for upstream there's also the requirement
>>> that we have open users and are not just enabling proprietary blob
>>> userspace, which makes any changes to dma-buf heaps for out of tree
>>> code quite difficult)
>>>
>>>> However, dma-buf usage identification becomes a challenge. A potential
>>>> solution could be heap_flags. the use of heap_flags seems ugly and
>>>> contrary to the intended design as you said, How aboult extending
>>>> dma_heap_allocation_data as follows?
>>>>
>>>> struct dma_heap_allocation_data {
>>>>         __u64 len;
>>>>         __u32 fd;
>>>>         __u32 fd_flags;
>>>>         __u64 heap_flags;
>>>>         __u64 buf_flags: // buf usage
>>>> };
>>>
>>> This would affect the ABI (forcing a new ioctl number).  And it's
>>> unclear what flags you envision as buffer specific (rather than heap
>>> specific as this patch suggested).
>>>
>>> I think we need more details about the specific problem you're seeing
>>> and trying to resolve.
>> This patch mainly focuses on optimization for Android scenarios. Let’s
>> discuss it on the issue website.
>> Bug: 344501512
> 
> Ok, we can do that if you need.
> 
> But if this is ever going to go upstream (and it's more and more
> important that we minimize out of tree technical debt), conversations
> about how to generalize this will need to happen on the list.
> We need a more complete design and test results to convince upstream to accept. 
Thank you again for your suggestion.

Brs, 
Hailong.
> thanks
> -john