Received: by 10.223.176.5 with SMTP id f5csp749266wra; Wed, 7 Feb 2018 06:59:38 -0800 (PST) X-Google-Smtp-Source: AH8x2243D0pz/ieSfnvborzxqaodQoe6IPlB1/kDBcgiPNLVwqsXLIkDJEm818YSQDJvcRn27jNB X-Received: by 2002:a17:902:221:: with SMTP id 30-v6mr6428562plc.134.1518015578141; Wed, 07 Feb 2018 06:59:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518015578; cv=none; d=google.com; s=arc-20160816; b=pOhsc/XD8zly2qvXsJcicYD+fs4EZRX6nhymQXhOzcNUNk8MrzJYJhMm1/lU/J2sCE Sw6okIF5uBDNKxQ1i8Ybvmmrs1sdG6Pfl3PI9BgDG5pC4Sia1NAt9l3vkOTa4WpLJ+q7 zC7deWMwGNz5wHNtnOIKDKFxQIYuWNs10jL14rKx712TYEc25QsB4SJqEK2PKqPs8WCu btqhuZc+/gWe090pgDt6b5iiyQ5eE0o1v5thpLK6sRNcpQTcjLgFzkjQ0emWQczxVToG YcyZBJoC7Fb93lbh+yPTIr5YW/xeSRef7ECA1jaDBoWUHCzNahoLPqG8uUjYTgeRIG61 +i6w== 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=D2aEilN06B1/EiDSIRGwT7MknbvJR/SyRqp2aW84BbQ=; b=D8BVxhmzk6h/oTwod5WCLzK2UckIOrSC4kQ9Y96UGWBfDDUD4r44v1WJiSVba3b12/ 7lZCLl+DSA5Of55VYosUXhxgL7heEQgZREa1L2zh+AEgdQdR1WlL2WYvXC8ghd7Ayc3w RbP0pL3JC7kA8O2gIxXgAJfb7uSnbTwsbgblvDB8wwnIDrQ2hpJ/jPCEGyzN8YyNPYHH wKtoMlGOfq2T5WDjzkrc3w354++SNsZHQkoH4AvkFB/1Xu24ETSAM/AOUTQ0igSd7X2f Wvo5eOHPxUJQ8Fyz3PLWaxD8Do/aUAeIrYXsjjIghARXTH+cDjMYmE4n0la76+bER6B7 LKVA== 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 m14si1024613pgr.249.2018.02.07.06.59.23; Wed, 07 Feb 2018 06:59:38 -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 S1754429AbeBGO6m (ORCPT + 99 others); Wed, 7 Feb 2018 09:58:42 -0500 Received: from mail-ot0-f173.google.com ([74.125.82.173]:40163 "EHLO mail-ot0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754380AbeBGO6k (ORCPT ); Wed, 7 Feb 2018 09:58:40 -0500 Received: by mail-ot0-f173.google.com with SMTP id s4so1034487oth.7 for ; Wed, 07 Feb 2018 06:58:40 -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=D2aEilN06B1/EiDSIRGwT7MknbvJR/SyRqp2aW84BbQ=; b=AAEmf6DSVvln+FC91qaaCicM+NUamElz4UpkKzU6ucZxj63MQLI/1Z03bKBrrS+ESP 8GrDo2HcazSJ9q2ylusE/PwakRFPbjXLPisbLtOc/oD7jRkI6/3BzQSIQDAhENqiFSuy ugTyyuKaqYCffAMnEN9bBl4IWLwY4xFEYxEBQ7pwnjygbJewY1vc6A/MZ7gsM42dAeOX LYxiXyykBMBCCbmlWkvL/OgHA2BXpqT5IQCyVJP6oRTiG0Cb3G1vs2QcGpLK1xq7L2CB WyphbyWxMz9WmxImU7/ZLJ9lT724zpuzXfWPTqAXhmM1zmfVnZcJUo8AW3ZBLwEmUm1S V9Wg== X-Gm-Message-State: APf1xPAiNyAkilmMZbiwmEA0oIKyhCqLess3IVyA9iVuWz6uyM7jIPlZ Z55SMuSNjFBBE2P6dviQKmsT6PeKCg0= X-Received: by 10.157.89.205 with SMTP id u13mr4257385otg.339.1518015519800; Wed, 07 Feb 2018 06:58:39 -0800 (PST) Received: from ?IPv6:2601:602:9802:a8dc::f21a? ([2601:602:9802:a8dc::f21a]) by smtp.gmail.com with ESMTPSA id k10sm750739otj.29.2018.02.07.06.58.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 06:58:38 -0800 (PST) Subject: Re: staging: ion: ION allocation fall back order depends on heap linkage order To: Alexey Skidanov , devel@driverdev.osuosl.org Cc: linux-kernel@vger.kernel.org References: <58951af2-a84e-7d7c-e956-ece3190aa8c2@redhat.com> <0217ee91-25fa-f563-81bd-ba4ad4dc9377@intel.com> From: Laura Abbott Message-ID: Date: Wed, 7 Feb 2018 06:58:36 -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: <0217ee91-25fa-f563-81bd-ba4ad4dc9377@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/06/2018 11:05 PM, Alexey Skidanov wrote: > > >> Yup, you've hit upon a key problem. Having fallbacks be stable >> was always a problem and the recommendation these days is to >> not rely on them. You can specify a heap at a time and fallback >> manually if you want that behavior. >> >> If you have a proposal to make fallbacks work reliably without >> overly complicating the ABI I'm happy to review it. >> >> Thanks, >> Laura >> > I think it's possible to "automate" the "manual fallback" behavior. But > the real issues is using heap id to specify the particular heap object. > > Current API (allocation IOCTL) requires to specify the particular heap > object by using heap id. From the other hand, the user space doesn't > control the heaps creation order and heap id assignment. So it may be > tricky, especially when more than one object of the same heap type is > created automatically. > > Thanks, > Alexey > > The query ioctl is designed to get the heap ID information without needing to rely on the linking order or anything else defined in the kernel. Thanks, Laura