Received: by 10.223.185.116 with SMTP id b49csp2621718wrg; Mon, 12 Feb 2018 12:48:41 -0800 (PST) X-Google-Smtp-Source: AH8x226TnBB/NXs6ODAfXq9I2RA+1Td8mwb+AQRMaKy2pqwPXuJhoyy+upbzzQWO8WTFCOwBWM2Z X-Received: by 10.99.166.2 with SMTP id t2mr10176894pge.234.1518468521072; Mon, 12 Feb 2018 12:48:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518468521; cv=none; d=google.com; s=arc-20160816; b=HPYD5BfZehPMz/KITb+dsYXUFGIGIsQbfla1hoo/JJ3bO5LyL0kQA7oUMd2k2WPHFA 5CDGKNvSOHTeQ5WJojPWVUTGY6kdUBt+q4CDljmJtN8gQUre7DgzPvrLYsOE/yQlQjnA o/XBg0O/BcbBWtT2BvXtlv6nl/Xn3Ri0i0nE2yVHxwJ0PqFrJgvXLMmPIjrvnCQwVNcc wnCkUQIZWvQ8KRCUDJa7NV3535GbXmfH38qP3hRgEqRzrmtyiywf/dNgGe1hNeQdUOB8 iPxdnixkARByL/3qnzaNfXT6MxV07bKhz7fiHhCd+Nn0T5Qb4H2EQ/l82XeOZ8OPjYM3 nh4g== 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=KHwl9FYz1dVjer4/RzhAznPw4+9H5Uw+OYX7eBe6p20=; b=YMNYlSIZZLt5gilUcYBRv+PzLZ0XPfTR7WTDh5blQZQWC1onN4O5VUvWJ8cm0iNVFr 8a6p4IJLjmgXVcAzXOcDILcf2QnHd3GwRCN1BaU6UiCjiCJqLcfY3O5BbVLbrV1btZp4 VMQAzK06bYTj1le3io85khUsps6domj4DAbBa18QEV3ZtfD/NxmaO7GHLd936+g67sKM iWaDljmxp219gpxeQIGqCn3fqCyZJIOqpUmjJLA+u5Bqt/upCXCaTjtY6c3XNxJJ1dkw 5B+PfD17hn+m8LYV1/Eeg4O0D+OHTl3EC+s3ecyYJOhmxjg8OCFg+HTYnCz3euajKZcv TRLw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k21si435455pfb.43.2018.02.12.12.48.25; Mon, 12 Feb 2018 12:48:41 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932285AbeBLUq4 (ORCPT + 99 others); Mon, 12 Feb 2018 15:46:56 -0500 Received: from mail-oi0-f66.google.com ([209.85.218.66]:38462 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932120AbeBLUqx (ORCPT ); Mon, 12 Feb 2018 15:46:53 -0500 Received: by mail-oi0-f66.google.com with SMTP id j15so12217395oii.5 for ; Mon, 12 Feb 2018 12:46:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KHwl9FYz1dVjer4/RzhAznPw4+9H5Uw+OYX7eBe6p20=; b=H6Yoe5bT+hXrdLYU4OpVfOj8ssRAqegkK1GEAm1hh2Yoqy0HhJYNRMKldSJH69fAIr mP4CMf2f70ceEjNA7HZAJNiCyHbXvY9WaiF/+JvB9O03rK2PYqLVjJ0L+V9hdrlgvf1I u66DgQzx5Ci+JMtCSUZYSjIHD2yJMpJ+MccG2QQhEUaRyh2joonCNSYUMl1WaxUt5oqZ 28nHNgGTdmF9LpZy98KKl7icsI+AgkbHoo8QETiQkvH5iEymrYOj9USXcrqKCogcYUPV 6yUZDP2T8qMD+tp/Z8oy3rGXxMLGLFjUowQVQYqFrXXF+sXR6m/kMUpdaOBs914tUEza eyYg== X-Gm-Message-State: APf1xPDOjW3nBITrncpVHHSDTEXoIFRBA4zePqfg9qF0ekdyNN1BX50G qTfWD3QNdGBvVkceXB6FUWLUuw== X-Received: by 10.202.239.69 with SMTP id n66mr9225815oih.25.1518468412510; Mon, 12 Feb 2018 12:46:52 -0800 (PST) Received: from ?IPv6:2601:602:9802:a8dc::f21a? ([2601:602:9802:a8dc::f21a]) by smtp.gmail.com with ESMTPSA id 38sm5095420ota.55.2018.02.12.12.46.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Feb 2018 12:46:51 -0800 (PST) Subject: Re: [PATCH] staging: android: ion: Add requested allocation alignment To: Alexey Skidanov , 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> <8eb1f6c9-e08d-c6a5-934a-c7e7873d79f2@intel.com> From: Laura Abbott Message-ID: Date: Mon, 12 Feb 2018 12:46:49 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <8eb1f6c9-e08d-c6a5-934a-c7e7873d79f2@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed 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 12:22 PM, Alexey Skidanov wrote: > > > 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; > }; > Something that was previously unused is now being used. That's a change in how the structure is interpreted which is an ABI change, especially since we haven't been checking that the __unused field is set to 0. > As an alternative, I may add __u64 heap_specific_param - but this will > change the ABI. But, probably it makes the ABI more generic? Why does the ABI need to be more generic? If we change the ABI we're stuck with it and I'd like to approach it as the very last resort. Thanks, Laura