Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3697757imm; Thu, 17 May 2018 13:06:25 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqrlUp/kmPEPmGjwR0gIUFnvvBqRmTlO+1zX5j3qWbMkigWDZJVbctcxfa1jqqBu00psBN/ X-Received: by 2002:a17:902:2826:: with SMTP id e35-v6mr6499601plb.348.1526587585302; Thu, 17 May 2018 13:06:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526587585; cv=none; d=google.com; s=arc-20160816; b=iGz6Ud7+qDiGfeqbVovHGVXLJlBqtUsNZvwi1PcJKoMIViOFnVC6HCniFqPWiK4jze bPK1Gum1alCQBFouS922w5FnrSb5pPv05FXW5z0Lg2tb6pam/BP3PYII1+ovXE0krN8+ dSDU8knN3105QROTQh3J6JBWJ2aTpnyZztPU+ayLSloVCLVytZNhVmgoHKTxkHskp6As H/AISG4Cap7CTNCWdSIxgrgUK3VuB4q1m3Fyu9Qzv7w6QBwLIopCWwRUDbWStI7Iy/5z l2I6n7uB3XEtv6BGjVd7GbG0r/6oYKMR0kPGm61xtjbbmpBc6Ko5vXXC6ofdJKzciQ29 3WEQ== 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=tb8xyoBdLAq3TL+M8MW8XqXwlacJmTnLm4d8EH3kx08=; b=fnRYB5uvNaeIoM8gtzSXkrijqt0gVZKYmNRdi8KcMHS9Z3YCbU+9ycUuzaswb5vGg6 121uThaQdmuRDs9N7XwKGRVQDsrW6wAenKPyGtYi1B44jYFItV6NJzCfFAUmQIaJFzfv 6t1bXkq6QzA8j2IOBo23lQITHNUl4/qk9QEK+eGa5wlmvEmRfBCSBqoNU0rbUAmYnga6 kly+jLoIK21q79wHCFa3RKPi8GgS3BuVNootB6VLj1KaTGnYF09ue+HEv6OoiUUnYsgT KGkGfgsbb4filLL6eKPaYJKx51Nvc3tNtjV/i38fSCkjO8UVATZweIY4N9gcD3bRHpU8 m8uw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=KDsfqeQL; dkim=pass header.i=@codeaurora.org header.s=default header.b=LmHsRxFv; 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 o11-v6si3844146pgr.310.2018.05.17.13.06.01; Thu, 17 May 2018 13:06:25 -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=KDsfqeQL; dkim=pass header.i=@codeaurora.org header.s=default header.b=LmHsRxFv; 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 S1751976AbeEQUFu (ORCPT + 99 others); Thu, 17 May 2018 16:05:50 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:57896 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751409AbeEQUFs (ORCPT ); Thu, 17 May 2018 16:05:48 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 351D7609D1; Thu, 17 May 2018 20:05:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1526587548; bh=99yqvtvRSAepCFqfbsa4UODCWFHKr7cafXTlES4Rgv0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=KDsfqeQLJiZnoeZU99zOkDMTMNY5wQv8cEWY3sQWLAtr+LDAQcgepsbKt7kN5gaiW uj9C1jRhA89QPiAhs5vPwaOPXuSgFXIUpkbFcpYNrkbsMxz5j1d7z7jVgg9h+HS2x0 tCO6+LfpvOB2D0WCXHmbLeD/87jWmjig+juEcJIw= 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 B4535602B8; Thu, 17 May 2018 20:05:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1526587547; bh=99yqvtvRSAepCFqfbsa4UODCWFHKr7cafXTlES4Rgv0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LmHsRxFvy8IESwVKaEmU+DEXuh+GafhpaqKdlUGHyyjKr2dTxC968aD+4fNa/T5Mc NV5uUaysavS8867Fl0kuv2Jdl3MtCM83NuYYiuGNnwhxqqVvKpHvl+dMvOMmZGhFsQ aim13OKCXI2davek3y7cTzzxIfaglspTImPo38kw= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org B4535602B8 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> <9844a638-bc4e-46bd-133e-0c82a3e9d6ea@codeaurora.org> <20180517194612.GG26718@bombadil.infradead.org> From: Sinan Kaya Message-ID: Date: Thu, 17 May 2018 16:05:45 -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: <20180517194612.GG26718@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 3:46 PM, Matthew Wilcox wrote: >> Remember that the CPU core that is running this driver is most probably on >> the same NUMA node as the device itself. > Umm ... says who? If my process is running on NUMA node 5 and I submit > an I/O, it should be allocating from a pool on node 5, not from a pool > on whichever node the device is attached to. OK, let's do an exercise. Maybe, I'm missing something in the big picture. If a user process is running at node 5, it submits some work to the hardware via block layer that is eventually invoked by syscall. Whatever buffer process is using, it gets copied into the kernel space as it is crossing a userspace/kernel space boundary. Block layer packages a block request with the kernel pointers and makes a request to the NVMe driver for consumption. Last time I checked, dma_alloc_coherent() API uses the locality information from the device not from the CPU for allocation. While the metadata for dma_pool is pointing to the currently running CPU core, the DMA buffer itself is created using the device node itself today without my patch. I would think that you actually want to run the process at the same NUMA node as the CPU and device itself for performance reasons. Otherwise, performance expectations should be low. Even if user says please keep my process to a particular NUMA node, we keep pointing to the memory on the other node today. I don't know what is so special about memory on the default node. IMO, all memory allocations used by a driver need to follow the device. I wish I could do this in kmalloc(). devm_kmalloc() follows the device as another example not CPU. With these assumptions, even though user said please use the NUMA node from the device, we still keep pointing to the default domain for pointers. Isn't this wrong? > > If it actually makes a performance difference, then NVMe should allocate > one pool per queue, rather than one pool per device like it currently > does. > >> 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. > * DMA Pool allocator > * > * Copyright 2001 David Brownell > * Copyright 2007 Intel Corporation > * Author: Matthew Wilcox > > I know what it's used for. > cool, good to know. -- 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.