From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicholas Piggin Subject: Re: [PATCH v2 4/4] mm/vmalloc: Hugepage vmalloc mappings Date: Tue, 14 Apr 2020 22:13:44 +1000 Message-ID: <1586864403.0qfilei2ft.astroid@bobo.none> References: <20200413125303.423864-1-npiggin@gmail.com> <20200413125303.423864-5-npiggin@gmail.com> <20200414072316.GA5503@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1729799AbgDNMPT (ORCPT ); Tue, 14 Apr 2020 08:15:19 -0400 In-Reply-To: <20200414072316.GA5503@infradead.org> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Christoph Hellwig Cc: Borislav Petkov , Catalin Marinas , "H. Peter Anvin" , linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, Ingo Molnar , Thomas Gleixner , Will Deacon , x86@kernel.org Excerpts from Christoph Hellwig's message of April 14, 2020 5:23 pm: > On Mon, Apr 13, 2020 at 10:53:03PM +1000, Nicholas Piggin wrote: >> For platforms that define HAVE_ARCH_HUGE_VMAP and support PMD vmap mappi= ngs, >> have vmalloc attempt to allocate PMD-sized pages first, before falling b= ack >> to small pages. Allocations which use something other than PAGE_KERNEL >> protections are not permitted to use huge pages yet, not all callers exp= ect >> this (e.g., module allocations vs strict module rwx). >>=20 >> This gives a 6x reduction in dTLB misses for a `git diff` (of linux), fr= om >> 45600 to 6500 and a 2.2% reduction in cycles on a 2-node POWER9. >>=20 >> This can result in more internal fragmentation and memory overhead for a >> given allocation. It can also cause greater NUMA unbalance on hashdist >> allocations. >>=20 >> There may be other callers that expect small pages under vmalloc but use >> PAGE_KERNEL, I'm not sure if it's feasible to catch them all. An >> alternative would be a new function or flag which enables large mappings= , >> and use that in callers. >=20 > Why do we even use vmalloc in this case rather than just doing a huge > page allocation? Which case? Usually the answer would be because you don't want to use contiguous physical memory and/or you don't want to use the linear=20 mapping. > What callers are you intersted in? The dentry and inode caches for this test, obviously. Lots of other things could possibly benefit though, other system=20 hashes like networking, but lot of other vmalloc callers that might benefit right away, some others could use some work to batch up allocation sizes to benefit. Thanks, Nick From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 716F5C2BB86 for ; Tue, 14 Apr 2020 12:17:45 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 227C820732 for ; Tue, 14 Apr 2020 12:17:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YPCaSFzn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 227C820732 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 491kyZ5g0tzDqch for ; Tue, 14 Apr 2020 22:17:42 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::541; helo=mail-pg1-x541.google.com; envelope-from=npiggin@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=YPCaSFzn; dkim-atps=neutral Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 491kvt6YJFzDqVF for ; Tue, 14 Apr 2020 22:15:20 +1000 (AEST) Received: by mail-pg1-x541.google.com with SMTP id h69so3369255pgc.8 for ; Tue, 14 Apr 2020 05:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=WHNX39DWF5Hlf3u8CwKDc+Fsn/bhcoFrdGg2YrrvOo0=; b=YPCaSFzn0oIdss6PgqWqExMDv2Ya4MqFKlIMtqX30ds70r7RnGgcscEiuorDHOmIxt bkg/vokkN/rRhBD6LJ9mw3mjhOahMg1Uwg9Qx2UNZFWTj0IMg9WnUDxB+ULJSCbA1ldn KSpVK42kxhB9z/aw0NH4UBeJI+KqGuxcHQoEPZCHcqOEDmAKdAwLZgWjuAma+5C/4TbG JmUnZp5MHDPoBd4ygsIhvDZ8ijEsX/e2wJi1VmDzroDN1oJ8TnkuqyUyr4ayZCZKIFK0 GcKo9BxipK0dpFhF+pZwLrt75E6HD72Q17JUhc4ZADldaZQrqxB3dU1lD6phiCSp3nG2 3WbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=WHNX39DWF5Hlf3u8CwKDc+Fsn/bhcoFrdGg2YrrvOo0=; b=kRnaEcbPkI8Lm4u1Ty2IVKKPUFYfkKFvFQ0OT0GrW+EpQ+2aC0jxWdjiTVKzcXtgfk xfVfE0lueapt87dL40JEYq2hNNJbW65eNj47/WxFLfTf3B2HhZCjvZnPAfSgXjt+IfJY rtMg3HRcZPdEiW4Q1o/+FEiKKKpjipf0TnCdXKI5p6lsexL402+Y895B2gd3YZ35h2zM ywCTk5SGoIg+r53h5yWyf/orqBfNHyDsVtx1PjM3vndOcju6j1zgO1eSoOs7ESm772OD 7lNXkClCst7mfDIKkHDK4tHj9rsDZFUokkOLw5VGnHwLFkuNavY/wPEuVAIqqnfzXJtR pI0w== X-Gm-Message-State: AGi0Puaq3LIFj/o0cJ98kyq9V40DsgmH8ZNaS9G0QmmWdffFn4uAa3Tt N0ZeFXYCBNg2JpM2LdAk6ko= X-Google-Smtp-Source: APiQypIal3O38c4Mqwm4P9dpr8g1+GmgXzDHXceCqIscl9w/plzTRFxfjFtpP2vU89kIf2d05y9VAA== X-Received: by 2002:a63:1820:: with SMTP id y32mr11205009pgl.182.1586866517492; Tue, 14 Apr 2020 05:15:17 -0700 (PDT) Received: from localhost ([203.18.28.220]) by smtp.gmail.com with ESMTPSA id h11sm10999819pfn.125.2020.04.14.05.15.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Apr 2020 05:15:16 -0700 (PDT) Date: Tue, 14 Apr 2020 22:13:44 +1000 From: Nicholas Piggin Subject: Re: [PATCH v2 4/4] mm/vmalloc: Hugepage vmalloc mappings To: Christoph Hellwig References: <20200413125303.423864-1-npiggin@gmail.com> <20200413125303.423864-5-npiggin@gmail.com> <20200414072316.GA5503@infradead.org> In-Reply-To: <20200414072316.GA5503@infradead.org> MIME-Version: 1.0 Message-Id: <1586864403.0qfilei2ft.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, Will Deacon , Catalin Marinas , x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Thomas Gleixner , linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Excerpts from Christoph Hellwig's message of April 14, 2020 5:23 pm: > On Mon, Apr 13, 2020 at 10:53:03PM +1000, Nicholas Piggin wrote: >> For platforms that define HAVE_ARCH_HUGE_VMAP and support PMD vmap mappi= ngs, >> have vmalloc attempt to allocate PMD-sized pages first, before falling b= ack >> to small pages. Allocations which use something other than PAGE_KERNEL >> protections are not permitted to use huge pages yet, not all callers exp= ect >> this (e.g., module allocations vs strict module rwx). >>=20 >> This gives a 6x reduction in dTLB misses for a `git diff` (of linux), fr= om >> 45600 to 6500 and a 2.2% reduction in cycles on a 2-node POWER9. >>=20 >> This can result in more internal fragmentation and memory overhead for a >> given allocation. It can also cause greater NUMA unbalance on hashdist >> allocations. >>=20 >> There may be other callers that expect small pages under vmalloc but use >> PAGE_KERNEL, I'm not sure if it's feasible to catch them all. An >> alternative would be a new function or flag which enables large mappings= , >> and use that in callers. >=20 > Why do we even use vmalloc in this case rather than just doing a huge > page allocation? Which case? Usually the answer would be because you don't want to use contiguous physical memory and/or you don't want to use the linear=20 mapping. > What callers are you intersted in? The dentry and inode caches for this test, obviously. Lots of other things could possibly benefit though, other system=20 hashes like networking, but lot of other vmalloc callers that might benefit right away, some others could use some work to batch up allocation sizes to benefit. Thanks, Nick From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F3137C2BB86 for ; Tue, 14 Apr 2020 12:15:23 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C82F22075E for ; Tue, 14 Apr 2020 12:15:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Gh+nJH58"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YPCaSFzn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C82F22075E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Message-Id:MIME-Version:In-Reply-To: References:To:Subject:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=XOdDNZmfwbXEQgsPhNIWBifLUcR0TUoN1x4hoWiEz6A=; b=Gh+nJH58sFGMfu b4k3AAz3rDkBtrnK4UUn1quwdRaMVhwXc2LlxPrDuSBbTECuyWqROil16d2fA5ivoVhjkQE5e9YFr 6IsEP9JIiIXsM/zaHEn6pEMZqfMSedGwjlxyf296RTEd1aBD+AbODd57+juURWBQKiqBdb4Q2U2EJ Gabd3R/U6qX8XA+o09IoMvQXZ5AfmqBjrwnihtxQAcYoHjsCHiijwebna0fgi6XqGxX5JqwaY3GF1 dkcGiQsc6BKSXcbl7NjtwKoZg2YWPmnjfqpk6TcvnD31xTC15NFCak3Pj2pIjmlBBrsUgk2LfxZUo 1GLaIcU7ehLNvQfelxZQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jOKTI-0006Gi-V6; Tue, 14 Apr 2020 12:15:20 +0000 Received: from mail-pf1-x441.google.com ([2607:f8b0:4864:20::441]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jOKTG-0006GC-8P for linux-arm-kernel@lists.infradead.org; Tue, 14 Apr 2020 12:15:19 +0000 Received: by mail-pf1-x441.google.com with SMTP id y25so3682070pfn.5 for ; Tue, 14 Apr 2020 05:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=WHNX39DWF5Hlf3u8CwKDc+Fsn/bhcoFrdGg2YrrvOo0=; b=YPCaSFzn0oIdss6PgqWqExMDv2Ya4MqFKlIMtqX30ds70r7RnGgcscEiuorDHOmIxt bkg/vokkN/rRhBD6LJ9mw3mjhOahMg1Uwg9Qx2UNZFWTj0IMg9WnUDxB+ULJSCbA1ldn KSpVK42kxhB9z/aw0NH4UBeJI+KqGuxcHQoEPZCHcqOEDmAKdAwLZgWjuAma+5C/4TbG JmUnZp5MHDPoBd4ygsIhvDZ8ijEsX/e2wJi1VmDzroDN1oJ8TnkuqyUyr4ayZCZKIFK0 GcKo9BxipK0dpFhF+pZwLrt75E6HD72Q17JUhc4ZADldaZQrqxB3dU1lD6phiCSp3nG2 3WbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=WHNX39DWF5Hlf3u8CwKDc+Fsn/bhcoFrdGg2YrrvOo0=; b=FQbplZ/d08MR42bATkWzMasyLQLsHA5JQDO3/L8NatUCWDZhYF91RIZ0gQVwKUeEPC LfGfoFF4X8bhtE8VQUfKgQHzYGyAr5lousY4WOyTY1syV/7zynCbaiTqaYkqiIQjTnp5 k7iV68dmQ3sv+dkP0vTgz/XfNbYSzF8KYrSccPp553oBSHaU+msMeGwBKyYOQb9/iOwl YOZyYxlOH/DTnkJNXt2SumKvBET8D053b2q9RYbOwml+TOnYsulIzeopKA9y9fl9sz93 Sv/viu9pdMrdyY6cKxQ5/pp7IizUpmkzd/fhj0sdGQlmv31n0qWP/Rn0+DxLpLAm17xW feaQ== X-Gm-Message-State: AGi0PuYdpNoFASHJQYuo9rdHg87y9/wKPqp18856O9vIWKs88fG6nun4 24Ez27pQKaxf4uAYspIoEn8= X-Google-Smtp-Source: APiQypIal3O38c4Mqwm4P9dpr8g1+GmgXzDHXceCqIscl9w/plzTRFxfjFtpP2vU89kIf2d05y9VAA== X-Received: by 2002:a63:1820:: with SMTP id y32mr11205009pgl.182.1586866517492; Tue, 14 Apr 2020 05:15:17 -0700 (PDT) Received: from localhost ([203.18.28.220]) by smtp.gmail.com with ESMTPSA id h11sm10999819pfn.125.2020.04.14.05.15.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Apr 2020 05:15:16 -0700 (PDT) Date: Tue, 14 Apr 2020 22:13:44 +1000 From: Nicholas Piggin Subject: Re: [PATCH v2 4/4] mm/vmalloc: Hugepage vmalloc mappings To: Christoph Hellwig References: <20200413125303.423864-1-npiggin@gmail.com> <20200413125303.423864-5-npiggin@gmail.com> <20200414072316.GA5503@infradead.org> In-Reply-To: <20200414072316.GA5503@infradead.org> MIME-Version: 1.0 Message-Id: <1586864403.0qfilei2ft.astroid@bobo.none> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200414_051518_299163_E8BA23D9 X-CRM114-Status: GOOD ( 10.82 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, Will Deacon , Catalin Marinas , x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Thomas Gleixner , linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Excerpts from Christoph Hellwig's message of April 14, 2020 5:23 pm: > On Mon, Apr 13, 2020 at 10:53:03PM +1000, Nicholas Piggin wrote: >> For platforms that define HAVE_ARCH_HUGE_VMAP and support PMD vmap mappings, >> have vmalloc attempt to allocate PMD-sized pages first, before falling back >> to small pages. Allocations which use something other than PAGE_KERNEL >> protections are not permitted to use huge pages yet, not all callers expect >> this (e.g., module allocations vs strict module rwx). >> >> This gives a 6x reduction in dTLB misses for a `git diff` (of linux), from >> 45600 to 6500 and a 2.2% reduction in cycles on a 2-node POWER9. >> >> This can result in more internal fragmentation and memory overhead for a >> given allocation. It can also cause greater NUMA unbalance on hashdist >> allocations. >> >> There may be other callers that expect small pages under vmalloc but use >> PAGE_KERNEL, I'm not sure if it's feasible to catch them all. An >> alternative would be a new function or flag which enables large mappings, >> and use that in callers. > > Why do we even use vmalloc in this case rather than just doing a huge > page allocation? Which case? Usually the answer would be because you don't want to use contiguous physical memory and/or you don't want to use the linear mapping. > What callers are you intersted in? The dentry and inode caches for this test, obviously. Lots of other things could possibly benefit though, other system hashes like networking, but lot of other vmalloc callers that might benefit right away, some others could use some work to batch up allocation sizes to benefit. Thanks, Nick _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel