From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C421EC433DF for ; Tue, 18 Aug 2020 20:56:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 658722063A for ; Tue, 18 Aug 2020 20:56:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="F7t4t8R2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 658722063A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 086E58D0011; Tue, 18 Aug 2020 16:56:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 038218D0001; Tue, 18 Aug 2020 16:56:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E68B08D0011; Tue, 18 Aug 2020 16:56:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0235.hostedemail.com [216.40.44.235]) by kanga.kvack.org (Postfix) with ESMTP id D207C8D0001 for ; Tue, 18 Aug 2020 16:56:11 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 9E383181AEF10 for ; Tue, 18 Aug 2020 20:56:11 +0000 (UTC) X-FDA: 77164896942.11.bikes44_4807c8327022 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 43E9F180F8B82 for ; Tue, 18 Aug 2020 20:56:11 +0000 (UTC) X-HE-Tag: bikes44_4807c8327022 X-Filterd-Recvd-Size: 6215 Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com [209.85.167.195]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Tue, 18 Aug 2020 20:56:10 +0000 (UTC) Received: by mail-oi1-f195.google.com with SMTP id z22so19179214oid.1 for ; Tue, 18 Aug 2020 13:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WVlaqaJEkLaogLxHkb59x+3913QcwhMo1tlZOm9AT0s=; b=F7t4t8R2e65gCr9vdIxnNuliGDt2ahdeDAfavI7tANLzu2aQ0/Dm9nm68MjGmfDIEn +INKamv7mBD5XwNAn5unHK7F4wcGpKBzLWiimwLuJuMjurd9FzQdSLd4A3XwNq4oZgON 0mJ1mp3STPu72DoEU6s2oGDaAPZc1d9iqm6UukG6YQUqg1rxoULI89OmVCHGV1I5M6PW LehxdYwb6AkyftI67q/r18iiMmsk+U2qcn2C0MXIx9alBu+BWFFFFCArG9HhsRjc+0Ow eHMsfDTsciu66LcErJpINTzl2QMt9ciDVh42trJ4L0rc+/x0fLt7IxkYDBuYtyO6wsbj 4YsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WVlaqaJEkLaogLxHkb59x+3913QcwhMo1tlZOm9AT0s=; b=LTMre37dHkWmCHaFxGAL5v2bgDnnA3mvSU/B8FS1TGfF6dHQ9ACyjcMUb8/27aciE6 DH8v6b4o7owfnvs/a5qp7V9UiYd5xZG2gKe+rKozddhBDfVXzhJdDxx2xaZix9Z0YgK+ hO706mB3fJNwDuvZjnyqIXZNcSDUz2XG4bsnQfZPnELrXwnXbYv0jNKN00JAw/rRmHvd psACFNYo/tIuRdTyNhmho5Y1zwfgOpY4rUGNsUe6MVsKBXjdLvZVx/c834oCVQOY3uFd /K7L2aYAkH15LMthR7Z89EZ+d3OWsUg6YpLoCZtq37PEBs6eI+NlrUIZMft49dP2cJQ3 UjyA== X-Gm-Message-State: AOAM531n2+2h/GnIW409VkOloo9JW09MSbTGmyWSp4zR1qzuCE/GIbU0 9aJ0HG4JQLwscL4cUcoTg3eHgszpXVjekhTN6v539g== X-Google-Smtp-Source: ABdhPJwbu8MfbO3BaVc7WQtY8gCaYLyN64siinjCbEFyrvhEdhXeVpE86gO8wO6noTbeRWOhZomU5kKcgOZGItaZTUA= X-Received: by 2002:aca:1117:: with SMTP id 23mr1367198oir.97.1597784170084; Tue, 18 Aug 2020 13:56:10 -0700 (PDT) MIME-Version: 1.0 References: <20200818080415.7531-1-hyesoo.yu@samsung.com> In-Reply-To: <20200818080415.7531-1-hyesoo.yu@samsung.com> From: John Stultz Date: Tue, 18 Aug 2020 13:55:59 -0700 Message-ID: Subject: Re: [PATCH 0/3] Chunk Heap Support on DMA-HEAP To: Hyesoo Yu Cc: Sumit Semwal , Minchan Kim , Andrew Morton , iamjoonsoo.kim@lge.com, joaodias@google.com, linux-mm , KyongHo Cho , Suren Baghdasaryan , vbabka@suse.cz, "Andrew F. Davis" , "(Exiting) Benjamin Gaignard" , Liam Mark , Laura Abbott , Brian Starkey , Christian Koenig , linux-media , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , lkml , Rob Herring , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 43E9F180F8B82 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Aug 18, 2020 at 12:45 AM Hyesoo Yu wrote: > > These patch series to introduce a new dma heap, chunk heap. > That heap is needed for special HW that requires bulk allocation of > fixed high order pages. For example, 64MB dma-buf pages are made up > to fixed order-4 pages * 1024. > > The chunk heap uses alloc_pages_bulk to allocate high order page. > https://lore.kernel.org/linux-mm/20200814173131.2803002-1-minchan@kernel.org > > The chunk heap is registered by device tree with alignment and memory node > of contiguous memory allocator(CMA). Alignment defines chunk page size. > For example, alignment 0x1_0000 means chunk page size is 64KB. > The phandle to memory node indicates contiguous memory allocator(CMA). > If device node doesn't have cma, the registration of chunk heap fails. > > The patchset includes the following: > - export dma-heap API to register kernel module dma heap. > - add chunk heap implementation. > - document of device tree to register chunk heap > > Hyesoo Yu (3): > dma-buf: add missing EXPORT_SYMBOL_GPL() for dma heaps > dma-buf: heaps: add chunk heap to dmabuf heaps > dma-heap: Devicetree binding for chunk heap Hey! Thanks so much for sending this out! I'm really excited to see these heaps be submitted and reviewed on the list! The first general concern I have with your series is that it adds a dt binding for the chunk heap, which we've gotten a fair amount of pushback on. A possible alternative might be something like what Kunihiko Hayashi proposed for non-default CMA heaps: https://lore.kernel.org/lkml/1594948208-4739-1-git-send-email-hayashi.kunihiko@socionext.com/ This approach would insteal allow a driver to register a CMA area with the chunk heap implementation. However, (and this was the catch Kunihiko Hayashi's patch) this requires that the driver also be upstream, as we need an in-tree user of such code. Also, it might be good to provide some further rationale on why this heap is beneficial over the existing CMA heap? In general focusing the commit messages more on the why we might want the patch, rather than what the patch does, is helpful. "Special hardware" that doesn't have upstream drivers isn't very compelling for most maintainers. That said, I'm very excited to see these sorts of submissions, as I know lots of vendors have historically had very custom out of tree ION heaps, and I think it would be a great benefit to the community to better understand the experience vendors have in optimizing performance on their devices, so we can create good common solutions upstream. So I look forward to your insights on future revisions of this patch series! thanks -john