Received: by 10.223.176.5 with SMTP id f5csp1793274wra; Sun, 28 Jan 2018 08:25:24 -0800 (PST) X-Google-Smtp-Source: AH8x224ZcW55jXEooZtiWwzoQzX+0XHC63yK+hTlL4RnU52uhz17g0sfebLdqx62qQuHBW9vM6LL X-Received: by 2002:a17:902:67c5:: with SMTP id g5-v6mr15581514pln.106.1517156724098; Sun, 28 Jan 2018 08:25:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517156724; cv=none; d=google.com; s=arc-20160816; b=KiqlsdhN2ZShZeQcR6FH6kQ66sMJir0k9Ny20WCmVAQQPKfTnhMPlyiw7OAELPsXYa OC5J3ojVOSo4Dqr3UtUKmz0stL/WyMobSFQDbV66zrmGtEI/e/Ydum8oeTIyt3wr7TbQ KI9KaCvnQkCUXlTMlCNflA2EqtMMdpER6ESIJZTNHGbUgWbCbpva41JBVugcfc0n1WI6 LViPXkWMWVeuz5mh9QQ0bLpDbm699qEjDgNkFuzy/eTKTMgMJ4h4i5Zy2NsEloJ+Oyk1 sUHNCroBNTLyUhiHIluik5/8KKHKxHnWAA4hHaiKYyMX8kjCtQMExLimb7Ny58bsHAj1 zYdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :mime-version:dkim-signature:arc-authentication-results; bh=tacisKGcshKGt1mY0DDWy6jwSXA2v+CRg6+OOOzJXpk=; b=c01vccRaJvD4sznzak20jETqto6LHxPLNHZ3HRIFYiqh6LAaxnxYWGwBLmvjGVytRR JSRZeZPd4a4+lvxKMU26SSob7Rk25JIRA0gQ00QKcaihqVnrHeDwyVToOdcWNB5693ch JylYarGyc2dc2qQ9CUXvXwFgwrdZwVav//gp3VAk5PwNNDWAB6/wl5hG6OGYAIN7TIpb AKmES0dh7xlOXnwsKaJ+YCDmwFtOyPJDJhWVxTJYJ8xi6yEg7Ftrkq92mCZhFnCGpiQj upNv4FQpqUJZyH2UTZW4OU63qW22+yF3ABkVibiLBhuSs9tE5W++dWzfIyS6NNGv+Jny mZSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=h8wrnYQv; 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=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q188si5969713pga.444.2018.01.28.08.25.10; Sun, 28 Jan 2018 08:25:24 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=h8wrnYQv; 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=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752073AbeA1QYX (ORCPT + 99 others); Sun, 28 Jan 2018 11:24:23 -0500 Received: from mail-oi0-f66.google.com ([209.85.218.66]:38957 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751674AbeA1QYV (ORCPT ); Sun, 28 Jan 2018 11:24:21 -0500 Received: by mail-oi0-f66.google.com with SMTP id j188so2011793oib.6 for ; Sun, 28 Jan 2018 08:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=tacisKGcshKGt1mY0DDWy6jwSXA2v+CRg6+OOOzJXpk=; b=h8wrnYQvxie7LMuULdy60P31c7DMskEexi7dpodx0/YZk9vs28k+uVULMqoeKMBP1w jz9NXSGHInCAzjaK5jeLsVB+EjTD1kiWF8cLJqRqx2Pff037Aq5PxVTcYYv66QxHTzGL kQB1Ls1xFa9K0DmALyPV1S+70cV5rPe5E69vdCELv3zUv1HFwwKFEE8eHLpg7V4PsJ1S 5xZK1SF/WorreFIY1S5ye7Bdrfj879tCYWor/omwLkdELGMTYNrw/tlquaZ15LKr7ZAz 1J+r+2AHyXjqRMABlvxfL6m3fvzqsmatE+77xFSn4MWsMV6XH+cVfquY30fI+HQQrGNX XO7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=tacisKGcshKGt1mY0DDWy6jwSXA2v+CRg6+OOOzJXpk=; b=eHDGrKtQHhkCz4YNG6SVRsNBgsDVtyvGgrKLM4l1bc4A8KcOCDLmF7iwKjJu8cSah8 4A85sslEu5edyDGf9aHGcJM9FzByPI0O9kXIXt/joWdRtOX6iosI3mIItEK+e7JvQLKI vvoXw7ZlfbFE0qWo/VUZXf+19N20tiNS/ZtAhEmJ3APfKF8frlhZzUaQqLJQFDm8BDKY lclwNT0Imo4ZfOskJ/FNXZ7nBd8nsBMbKEBcIZ139fOOLstHhcCwoqJQxu2mnyUoWznh cfVMvLuLEzB/3Oyz8JbdvWQuEeDW01yarq+t//1mZ6HalzQQjagyIsNO+I1zkQBxrGRT Be2g== X-Gm-Message-State: AKwxytc43nvZKlQ7ADc74y0wSRPr817SEuhIQfHW0Md5GeH94/w9ju3P 4ZgDNEuub9nt8q2IxqaB4QgB5vS+E5qyWiY1FpA= X-Received: by 10.202.171.207 with SMTP id u198mr5472825oie.253.1517156661272; Sun, 28 Jan 2018 08:24:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.36.44 with HTTP; Sun, 28 Jan 2018 08:24:20 -0800 (PST) From: Alexey Skidanov Date: Sun, 28 Jan 2018 18:24:20 +0200 Message-ID: Subject: staging: ion: ION allocation fall back order depends on heap linkage order To: devel@driverdev.osuosl.org Cc: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, According to my understanding, the allocation fall back order completely depends on heap->id that is assigned during the heap creation: plist_for_each_entry(heap, &dev->heaps, node) { /* if the caller didn't specify this heap id */ if (!((1 << heap->id) & heap_id_mask)) continue; buffer = ion_buffer_create(heap, dev, len, flags); if (!IS_ERR(buffer)) break; } On creation, each heap is added to the priority list according to the priority assigned: ... static int heap_id; ... void ion_device_add_heap(struct ion_heap *heap) { ... heap->id = heap_id++; ... } The order of creation is the order of linkage defined in the Makefile. Thus, by default, we have: heap id 2, type ION_HEAP_TYPE_DMA heap id 1, type ION_HEAP_TYPE_SYSTEM heap id 0, type ION_HEAP_TYPE_SYSTEM_CONTIG Changing the linkage order: diff --git a/drivers/staging/android/ion/Makefile b/drivers/staging/android/ion/Makefile index bb30bf8..e05052c 100644 --- a/drivers/staging/android/ion/Makefile +++ b/drivers/staging/android/ion/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o -obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o +obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o I get the following order: heap id 2, type ION_HEAP_TYPE_SYSTEM heap id 1, type ION_HEAP_TYPE_SYSTEM_CONTIG heap id 0, type ION_HEAP_TYPE_DMA So, if the user specifies more than 1 heap in the heap_id_mask during allocation, the allocation fall back order completely depends on the order of linkage. Probably, it's better to let the user to define the fall back order (and NOT to be dependent on the linkage order at all) ? Thanks, Alexey