Received: by 10.223.176.5 with SMTP id f5csp788450wra; Wed, 7 Feb 2018 07:34:25 -0800 (PST) X-Google-Smtp-Source: AH8x2243kyY5bGnttWc5C1Q+d64aeUqRicaVFi/nqwuosvTu811Eb8lTu84oSRcl6JfUQwqbJw9C X-Received: by 2002:a17:902:6c41:: with SMTP id h1-v6mr6391447pln.25.1518017665155; Wed, 07 Feb 2018 07:34:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518017665; cv=none; d=google.com; s=arc-20160816; b=Dm/xibnBYJUQdJ6gI7+RfhcgUtFTIEJBjx7I9tMNy0+l5YL3Ksv4tuFVP2RPoW5c9f x66ArxX17fH3r2d3uYycoEbf/PDF5XvKi8Fi/xV0f8/TUp1Ze5kuEe09EMlrIo/bU6c+ Q9w6FfZdAvskvGUu3aqVBwvSvaqKWQ/zzjLUrq2vHs/+5Y8DNp4yoyYJpvX+cBa2RiqK KFZHj/zzKxlG9LJfoEyaj00xUAzSBeOSxQ58+k2tlQT2vDX1OnUCuD8DZ7WBUkRQQdUL YgSEURWZ6DVDYXYhWS5Ix5454EZsPeTHERdCA3tC28N0EfWiR2FYDhZtmi8Nc2bqpO2A uJrA== 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=g8L3XkcmJKHrxTxZQhCNJ6iIHjtWB+pIuZe1rHo3DRg=; b=TCWU828mYWHZSOGve8isltGLveJP6JMXqOAX0RhKA82LNte57/X50G5PEfW+IgpEkJ NTLtYJdilpiHSahTZamQwtYQsHnlYuqfy0aEgl8tZeebpYNVnHnAdB2Meu8e2yQjYJr9 +lWBOH99TI5wqUPKgLwHI2dEB9UOMEm7jn65X9RRzqpwTkHSAiBHPpw6Tr85PfviGd6r x7jEC22F9rTIUedNgQiQbu4cL04qvEAkKtccel98+JFQaAPglzE+6yYAV/BF0N2dDZOZ 7YXGzW1UbzEsLTMzeZutI8oho/ztE8BRwOazCKnIf+KRTzSUaEN3z1tWLozeCTwHIgfa OjgQ== 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 y73-v6si1236816plh.48.2018.02.07.07.34.09; Wed, 07 Feb 2018 07:34:25 -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 S1754528AbeBGPc6 (ORCPT + 99 others); Wed, 7 Feb 2018 10:32:58 -0500 Received: from mail-oi0-f48.google.com ([209.85.218.48]:43794 "EHLO mail-oi0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754343AbeBGPc5 (ORCPT ); Wed, 7 Feb 2018 10:32:57 -0500 Received: by mail-oi0-f48.google.com with SMTP id 4so929692ois.10 for ; Wed, 07 Feb 2018 07:32:57 -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=g8L3XkcmJKHrxTxZQhCNJ6iIHjtWB+pIuZe1rHo3DRg=; b=mtXj6PX+l3fA3Zd+mTcHkOC0znHN62D11vchquuzC2gp/LmHgw+URFArcmSFJk+cfM ohhu8W32MAdXXgCKpmumGgEE+D44u+BnyzipQ5ckkZJ5JLrDVUpfsH5xfj2E1A2MP+/e rP43raZdE2oJPzmZiPunNw2k78YigiQ3xSDL42XLe+GlFbByt0DlvSURGwpjj8VYJX2i eI72Zm/4tYjrHdnEIATZZbseG8BA5fMGFTlXxymRd8R4k0ZYEnXjN57nC80KUp1xSuBB kpw52KokxK9whDzV65dvrJ3dVBRkoE03r4I7BFwSVhnyi/FV+1BS6ukjJTQ1xVMG6Qp/ oFwg== X-Gm-Message-State: APf1xPBfMdsDxg+H7EkwfeCKfSKZfFcc70nSCeZXZfLsEHcjajkeWFcr 6CepQgVIz86Avy56inhdjjnAQnq7zzk= X-Received: by 10.202.4.65 with SMTP id 62mr4434682oie.136.1518017576745; Wed, 07 Feb 2018 07:32:56 -0800 (PST) Received: from ?IPv6:2601:602:9802:a8dc::f21a? ([2601:602:9802:a8dc::f21a]) by smtp.gmail.com with ESMTPSA id n132sm700649oia.0.2018.02.07.07.32.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 07:32:55 -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> <3f77b591-6248-da0a-e20d-88ca26a60a95@intel.com> From: Laura Abbott Message-ID: <9aab5e55-a2f1-b05d-3568-0a4491ff51f1@redhat.com> Date: Wed, 7 Feb 2018 07:32:53 -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: <3f77b591-6248-da0a-e20d-88ca26a60a95@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/07/2018 07:10 AM, Alexey Skidanov wrote: > > > On 02/07/2018 04:58 PM, Laura Abbott wrote: >> 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 > > That is true. But if we have 2 *automatically created* heaps of the same > type, how userspace can distinguish between them? > > Thanks, > Alexey > The query ioctl also gives the name which should be different for each heap. It's not ideal but the name/heap type are the best way to differentiate between heaps without resorting to hard coding. Thanks, Laura