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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 E9F4DC31E4B for ; Fri, 14 Jun 2019 15:05:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CCB1121721 for ; Fri, 14 Jun 2019 15:05:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725991AbfFNPFi (ORCPT ); Fri, 14 Jun 2019 11:05:38 -0400 Received: from foss.arm.com ([217.140.110.172]:36296 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725780AbfFNPFi (ORCPT ); Fri, 14 Jun 2019 11:05:38 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4E8F2344; Fri, 14 Jun 2019 08:05:37 -0700 (PDT) Received: from [10.1.197.57] (e110467-lin.cambridge.arm.com [10.1.197.57]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5B1F93F246; Fri, 14 Jun 2019 08:05:34 -0700 (PDT) Subject: Re: [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous To: 'Christoph Hellwig' , David Laight Cc: Maxime Ripard , Joonas Lahtinen , "dri-devel@lists.freedesktop.org" , "linux-mm@kvack.org" , "devel@driverdev.osuosl.org" , "linux-s390@vger.kernel.org" , "linux-rdma@vger.kernel.org" , David Airlie , "linux-media@vger.kernel.org" , Intel Linux Wireless , "intel-gfx@lists.freedesktop.org" , Maarten Lankhorst , Jani Nikula , Ian Abbott , Rodrigo Vivi , Sean Paul , "moderated list:ARM PORT" , "netdev@vger.kernel.org" , "linux-wireless@vger.kernel.org" , "linux-kernel@vger.kernel.org" , H Hartley Sweeten , "iommu@lists.linux-foundation.org" , Daniel Vetter References: <20190614134726.3827-1-hch@lst.de> <20190614134726.3827-17-hch@lst.de> <20190614145001.GB9088@lst.de> From: Robin Murphy Message-ID: <4113cd5f-5c13-e9c7-bc5e-dcf0b60e7054@arm.com> Date: Fri, 14 Jun 2019 16:05:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190614145001.GB9088@lst.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On 14/06/2019 15:50, 'Christoph Hellwig' wrote: > On Fri, Jun 14, 2019 at 02:15:44PM +0000, David Laight wrote: >> Does this still guarantee that requests for 16k will not cross a 16k boundary? >> It looks like you are losing the alignment parameter. > > The DMA API never gave you alignment guarantees to start with, > and you can get not naturally aligned memory from many of our > current implementations. Well, apart from the bit in DMA-API-HOWTO which has said this since forever (well, before Git history, at least): "The CPU virtual address and the DMA address are both guaranteed to be aligned to the smallest PAGE_SIZE order which is greater than or equal to the requested size. This invariant exists (for example) to guarantee that if you allocate a chunk which is smaller than or equal to 64 kilobytes, the extent of the buffer you receive will not cross a 64K boundary." That said, I don't believe this particular patch should make any appreciable difference - alloc_pages_exact() is still going to give back the same base address as the rounded up over-allocation would, and PAGE_ALIGN()ing the size passed to get_order() already seemed to be pointless. Robin.