Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3672449imm; Thu, 17 May 2018 12:37:50 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoHpMSSCdHLRfhN2wSURp7VSBAppC9zelkaqv1KFllu9WXNQ8i+dLdEYl8eK2J2LgLnG6e0 X-Received: by 2002:a17:902:aa98:: with SMTP id d24-v6mr6372102plr.185.1526585870210; Thu, 17 May 2018 12:37:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526585870; cv=none; d=google.com; s=arc-20160816; b=jduBUNnzMlamN+mJPCea7FhJ2h+k8609KP+F4/0l57fgjpGgeNn2/rKnOUWs/yS4Oy cMMYF7YYLYxwCRgaw1+1bxyzZoAvLWAkza93d/lxaV1I2IVXjWdMsi/8+CyaL/UsDpqw DDj81HZuK5Y0ItBc8x5VnlgXp711IUd13vXC2UECvrPQp81Fe1hvySfVZron34+Z31bA egVkLRkvPB18WMu+RdB85zk+LjRHikc21dd9urbL+xLwlLZppBtfz9fy2WygJhfZ6u92 CtB2Kbv5399hFQXMtdS55Q8iSF7QQDaK6GiIWQQHoNuGLLWX9PbIXXjZ1x+iqe58OgnP /i8Q== 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:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=6CqAelQEFm5Wl9UhLTkCp0S71XRj6K7UnZvnnqZo0s4=; b=aWWL5BJtYeqAkLHE+9kpvBL15jWiK6G+lxCjPkF6hOj+3wAYAHypW7xsIFQHWC3SPi HiIjhFWodMufee9mGHXufLky+kZB0I7VPzvtrY3K1dupfrpJKHQCX59xwtXCVQ6wsMrs +745ha0HTidO5dnSsR/pLvrqonMuAQc1t7QpWHQanZ8lD3aUdzUfY3UKVyM4RI2FKezw CEuHBSnnCYNSh6nTFX4h5hh7T7jKlz3EeojtGKM/zzIMC4TO/S5WR+kkRYbEnqZStPUT yON4gqOxYRaiJqI+8V3vMglKY0eoPYX7JztSIyLHZOVzFTkcvcgENTg0uQS/z5XID1TT 8NIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=NKNEXyuP; dkim=pass header.i=@codeaurora.org header.s=default header.b=NKNEXyuP; 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 22-v6si1474798pgh.407.2018.05.17.12.37.35; Thu, 17 May 2018 12:37:50 -0700 (PDT) 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=@codeaurora.org header.s=default header.b=NKNEXyuP; dkim=pass header.i=@codeaurora.org header.s=default header.b=NKNEXyuP; 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 S1751671AbeEQThZ (ORCPT + 99 others); Thu, 17 May 2018 15:37:25 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:43404 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750924AbeEQThY (ORCPT ); Thu, 17 May 2018 15:37:24 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id BC61B60131; Thu, 17 May 2018 19:37:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1526585843; bh=8GBVld/X+1BbvZWBZec8etia87+XZ/8RQ/i5V8A3Ozk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NKNEXyuPPDJVBqBtOhf/FT3KuczIyNq8sRlhfR5xnqIwzJamg5Nq9BdJyVstzApSy v8KOp3BIEDem09mWfaICiNZUdnM+Ngens8IDttFmZO5LxJeJZrtHq0RQgE9ZNRmXDL tiSgwOlfN/ukCBqniHOpkXXblJd6ppK9+ePJhb5Q= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [10.235.228.150] (global_nat1_iad_fw.qualcomm.com [129.46.232.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: okaya@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id A5EE7602B6; Thu, 17 May 2018 19:37:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1526585843; bh=8GBVld/X+1BbvZWBZec8etia87+XZ/8RQ/i5V8A3Ozk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NKNEXyuPPDJVBqBtOhf/FT3KuczIyNq8sRlhfR5xnqIwzJamg5Nq9BdJyVstzApSy v8KOp3BIEDem09mWfaICiNZUdnM+Ngens8IDttFmZO5LxJeJZrtHq0RQgE9ZNRmXDL tiSgwOlfN/ukCBqniHOpkXXblJd6ppK9+ePJhb5Q= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org A5EE7602B6 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=okaya@codeaurora.org Subject: Re: [PATCH] mm/dmapool: localize page allocations To: Matthew Wilcox Cc: linux-mm@kvack.org, timur@codeaurora.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, open list References: <1526578581-7658-1-git-send-email-okaya@codeaurora.org> <20180517181815.GC26718@bombadil.infradead.org> From: Sinan Kaya Message-ID: <9844a638-bc4e-46bd-133e-0c82a3e9d6ea@codeaurora.org> Date: Thu, 17 May 2018 15:37:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180517181815.GC26718@bombadil.infradead.org> 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 On 5/17/2018 2:18 PM, Matthew Wilcox wrote: > On Thu, May 17, 2018 at 01:36:19PM -0400, Sinan Kaya wrote: >> Try to keep the pool closer to the device's NUMA node by changing kmalloc() >> to kmalloc_node() and devres_alloc() to devres_alloc_node(). > Have you measured any performance gains by doing this? The thing is that > these allocations are for the metadata about the page, and the page is > going to be used by CPUs in every node. So it's not clear to me that > allocating it on the node nearest to the device is going to be any sort > of a win. > It is true that this is metadata but it is one of the things that is most frequently used in spite of its small size. I don't think it makes any sense to cross a chip boundary for accessing a pointer location on every single pool allocation. Remember that the CPU core that is running this driver is most probably on the same NUMA node as the device itself. Also, if it was a one time init kind of thing, I'd say "yeah, leave it alone". DMA pool is used by a wide range of drivers and it is used to allocate fixed size buffers at runtime. Performance impact changes depending on the driver in use. This particular code is in use by network adapters as well as the NVMe driver. It does have a wide range of impact. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.