Received: by 10.223.185.116 with SMTP id b49csp2602219wrg; Mon, 12 Feb 2018 12:23:53 -0800 (PST) X-Google-Smtp-Source: AH8x2266S+S7onCYbyLUCj3El/WuugWcfr6d/skJ5HK5c+idMwzE+IkHLVPRkVqGTzN4EYXP3ym3 X-Received: by 2002:a17:902:594c:: with SMTP id e12-v6mr4314211plj.323.1518467033423; Mon, 12 Feb 2018 12:23:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518467033; cv=none; d=google.com; s=arc-20160816; b=bZ2FBVdiR5eEIZwHgh6J0TX9XAF6gZ4TpoJqXX9cSKwN62cc52Wk1u1vwuSSEGK7/H UfTIDR1gXfJoGkDquxmS8n75YbyGtvWnAuT+ICuuBKdvGOCGEqXPPZvwc8ANL4Jn6ivh lgdo3vRYv8v+qhDoUEjiPmFGc3IG0y6yDK05Oj5H35896gEgxShCOtfU5pRdVL5DOXqY pbA+WCS7ujINTN4LX75V33Zh02FHPdZzEAr8UA/FXNbbOyxV0HeJvkwxidixe+KZzhAS m9mJa0JKJy16Dt191qVwHZXmDdrsRvds3iy7A3tSAWlzk8pTfjoerL1aYVQQdns1Io4/ jesA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=i5n5eWwg6U2aGHO9Gl4jQJ8ee3kV6pkzkapI9vNP5/I=; b=bHVqOBDkGGZMy54XMOVZ+38iaJwnEvWQmSE+Gf4+5kxbv8or2Ner2fcLjb8EAClUl9 4JttkjpP02euFmhrC2cpxeoqtRvl480djzOTTj7iWsk4LYz/f4gjSqeRz4U+BSvTEOud lUtDk9crTZyCXlNPsvPV/r/WH18TpAZdwJOr3LGW8Wt2sanbT0gT1hsuSTtyYdsNFe2n nRhAvuLu25nf83I06+Zllb9FkiIjUKFfTHDc4xY3hI3kuMGhKCsYozE8uj0IGucmq9cJ cBK3EuO58yA5RqgC2X/gtb79fna2WHBP6OcKoTKDOm85EbWbUJWdqWRoIr++9QpRnw/y El6w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 141si2585030pga.176.2018.02.12.12.23.39; Mon, 12 Feb 2018 12:23:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754014AbeBLUWI (ORCPT + 99 others); Mon, 12 Feb 2018 15:22:08 -0500 Received: from mga14.intel.com ([192.55.52.115]:12334 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752166AbeBLUVy (ORCPT ); Mon, 12 Feb 2018 15:21:54 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2018 12:21:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,503,1511856000"; d="scan'208";a="26757161" Received: from alexey-system-product-name.iil.intel.com (HELO [10.236.193.131]) ([10.236.193.131]) by FMSMGA003.fm.intel.com with ESMTP; 12 Feb 2018 12:21:34 -0800 Subject: Re: [PATCH] staging: android: ion: Add requested allocation alignment To: Laura Abbott , sumit.semwal@linaro.org, gregkh@linuxfoundation.org, arve@android.com, tkjos@android.com, maco@android.com, devel@driverdev.osuosl.org Cc: linux-kernel@vger.kernel.org, Liam Mark References: <1518257863-6903-1-git-send-email-alexey.skidanov@intel.com> <8284b2ba-a532-23fd-4c52-7ac556d63918@intel.com> From: Alexey Skidanov Message-ID: <8eb1f6c9-e08d-c6a5-934a-c7e7873d79f2@intel.com> Date: Mon, 12 Feb 2018 22:22:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/12/2018 09:52 PM, Laura Abbott wrote: > On 02/12/2018 11:11 AM, Alexey Skidanov wrote: >> >> On 02/12/2018 08:42 PM, Laura Abbott wrote: >>> On 02/10/2018 02:17 AM, Alexey Skidanov wrote: >>>> Current ion defined allocation ioctl doesn't allow to specify the >>>> requested >>>> allocation alignment. CMA heap allocates buffers aligned on buffer size >>>> page order. >>>> >>>> Sometimes, the alignment requirement is less restrictive. In such >>>> cases, >>>> providing specific alignment may reduce the external memory >>>> fragmentation >>>> and in some cases it may avoid the allocation request failure. >>>> >>> I really do not want to bring this back as part of the regular >>> ABI. >> Yes, I know it was removed in 4.12. >> Having an alignment parameter that gets used for exactly >>> one heap only leads to confusion (which is why it was removed >>> from the ABI in the first place). >> You are correct regarding the CMA heap. But, probably it may be used by >> custom heap as well. > > I can think of a lot of instances where it could be used but > ultimately there needs to be an actual in kernel user who wants > it. > >>> The alignment came from the behavior of the DMA APIs. Do you >>> actually need to specify any alignment from userspace or do >>> you only need page size? >> Yes. If CMA gives it for free, I would suggest to let the ion user to >> decide > > I'm really not convinced changing the ABI yet again just to let > the user decide is actually worth it. If we can manage it, I'd > much rather see a proposal that doesn't change the ABI. I didn't actually change the ABI - I just use the "unused" member: struct ion_allocation_data { @@ -80,7 +79,7 @@ struct ion_allocation_data { __u32 heap_id_mask; __u32 flags; __u32 fd; - __u32 unused; + __u32 align; }; As an alternative, I may add __u64 heap_specific_param - but this will change the ABI. But, probably it makes the ABI more generic? > >>> Thanks, >>> Laura >>> >> Thanks, >> Alexey >> > Thanks, Alexey