Received: by 10.223.176.5 with SMTP id f5csp309937wra; Tue, 6 Feb 2018 23:05:55 -0800 (PST) X-Google-Smtp-Source: AH8x225siHBfB61CWJrg+Xs6WNviJ3SaT9H262DeuSqwK4GuSuzlVfTwNwW8bNEyljfcFEiW2oGl X-Received: by 10.98.71.84 with SMTP id u81mr5036806pfa.204.1517987155804; Tue, 06 Feb 2018 23:05:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517987155; cv=none; d=google.com; s=arc-20160816; b=niY5Kb8T+aursgfgBR+BEw0Gdci5TMsuynG5kKhJdqEgqaPtLKQU4MtPod1MAQGwdE lkYfyP9hBgz8VrKZs1JF8DLFZSmDip/TK7llXqkmk15GRD0yefzu7Er28cS0HoRm9Gpy 8LiYtE5moOuZONPkN1jYjQcyCHv4NR5l0tk8CEKWGkQh59h9N8q6lxIWxTSBza4PpUBW RG+fCjpCsQ1OQDRn8NMuKTXyW54ieoboAuhPjGn6GeymrywMsUClcZ3iWxnuwDWZ5kP7 Eh2dwQApSB3UYhgUI6OvUDarruJWy/cZBkcL0tumZ3C65kBdiF64rnLAQSzZmOq55OYR E/0A== 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:cc:from:references:to:subject:arc-authentication-results; bh=YdBeTUi9hVu3cgjv7iuj0Bmjo3XdKJJ1Uc1nYF1CwmA=; b=puVwtaoFdTjw68zuA5DMgerP6ownsCSnImn2GDgratfzs1TVe6vn9Ea0g+dNA7nYpK misoQn6re9O1YxZPDQEnJ22GXEkPc6V+leVl4hKqJ4ckTO0kXEPu0QbWhOlJ6PEpxC1n BcEpfxMH4yAOMeJf3tcy5woxnKU8qENE7Yxxje9GwDLy+h74VZHpiLbtpc7yyk/uUMe8 NGOuSgghfl0s3sFihhuK5bKJhkDgtdVrnD8SvCtkyasNfdapmBMncQdfmqYu+GVRRmVk p3u6iOBn9RbosNCwbPKyGJMKWj/I5TvyebxCWv2XYfq8P4rARFu4uVParRuWbAMAt7ZC /cnQ== 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 g12-v6si657493pla.338.2018.02.06.23.05.42; Tue, 06 Feb 2018 23:05:55 -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 S1753390AbeBGHFD (ORCPT + 99 others); Wed, 7 Feb 2018 02:05:03 -0500 Received: from mga06.intel.com ([134.134.136.31]:24209 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751269AbeBGHFC (ORCPT ); Wed, 7 Feb 2018 02:05:02 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2018 23:05:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,471,1511856000"; d="scan'208";a="17868506" Received: from alexey-system-product-name.iil.intel.com (HELO [10.236.193.131]) ([10.236.193.131]) by fmsmga002.fm.intel.com with ESMTP; 06 Feb 2018 23:04:55 -0800 Subject: Re: staging: ion: ION allocation fall back order depends on heap linkage order To: Laura Abbott , devel@driverdev.osuosl.org References: <58951af2-a84e-7d7c-e956-ece3190aa8c2@redhat.com> From: Alexey Skidanov Cc: linux-kernel@vger.kernel.org Message-ID: <0217ee91-25fa-f563-81bd-ba4ad4dc9377@intel.com> Date: Wed, 7 Feb 2018 09:05:22 +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 > 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