Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp499245ybi; Thu, 11 Jul 2019 23:38:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqz+J5OKWKq9i4P55Uy++LfjCFOTAJVGTadMQxZsUHtmMMoovljrJKzwm5FT9tOInTOnAiOe X-Received: by 2002:a17:90a:3086:: with SMTP id h6mr9931259pjb.14.1562913486378; Thu, 11 Jul 2019 23:38:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562913486; cv=none; d=google.com; s=arc-20160816; b=hqe2EdXTz3BkzJKmFK5i3yUYMaE8dT2K749HNifUYBCnrRxbA+iDPMYJFaD2Z+bLWT dL/U/JP8FtMxiLQoTG2S7WqGVQgQDbbtLZLbnFkASWhZwTheWFnN5k3N1Whu3L08WR3+ +b6Y/3hYsQskv/XqUpu4VcPIP96Rve9COTPiX3l1Ff4daWUrXYySF5KKzH7gEFJikoBB OnxetLKsU4mlOcQyVrHfUvUB3GkbMAO5HgjcwLx5DbK7UcZJnM8RhT7/K9vEwVLcAkqM NG3fufjJsjbDOlUizHZHpa0H3acObyBS/4w7czT1sMbI11wn1Q+CAt70uwTcuNKdetL0 NWuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:content-transfer-encoding:mime-version :message-id:date:subject:cc:from:dkim-signature; bh=9fgLR31T2kJ7ByeAcyeu1jTET3a3Az2KgII9UYX7QS4=; b=IzBxLrUNHeyqUKVqfq/W1DWJ7rQcSqVyXaU6U6jwfpxwORvAqHnl4x/5ui+G/iQQU+ kuF6zc3iUUkY1QOk1BfIS4wU7G0tu9XnO8hw1x2vBc5uvozscMY6lCOAK+NDG58/boQw cfRfmvqB8MObK5RCZCIVEZuKLHnb7WmfeVOtsStK5qY2XKq7FbXYjaV9tB6zbkNk7ldt yhOJWPxFgtnvOOr7297XQD7L08bPHt43BuUUpxcQ2FCmuZiDblrKSqkJn6zC1ymjMOs9 vl1glic2eaojOUBYENQj+zXnGcF784RUA0BZ/XJ4kyziC8lXn0QyYQd1lhVHED6QlsLu s2fQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=sBxoqPDX; 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 q8si7005195pjp.61.2019.07.11.23.37.50; Thu, 11 Jul 2019 23:38:06 -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=fail header.i=@gmail.com header.s=20161025 header.b=sBxoqPDX; 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 S1726061AbfGLGhY (ORCPT + 99 others); Fri, 12 Jul 2019 02:37:24 -0400 Received: from mail-pl1-f196.google.com ([209.85.214.196]:34787 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725562AbfGLGhY (ORCPT ); Fri, 12 Jul 2019 02:37:24 -0400 Received: by mail-pl1-f196.google.com with SMTP id i2so4296391plt.1 for ; Thu, 11 Jul 2019 23:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=9fgLR31T2kJ7ByeAcyeu1jTET3a3Az2KgII9UYX7QS4=; b=sBxoqPDXu79GyIN83gqFvlOD8ZHmRtzdZstCyRXyHO9B2E1nMqqBiWvC0jVA3cm31V fPQgy9hD8jqllKrNvGVQg8Sk44E6VqOC5uAab+osHEk1qP/V4guf8AnM3K1oiBLBugoY KubIQQLK3vNOYqtK8h/C5dkmTFTbfFdnqXDxz513rCe2r1SPksvbwlIifKGr6gC5lzYK eZ2Fg9zUPEnFAjryZV6PAr9N/lCa3Vif4f+oejO2glcrjdpVRWSMK6p87iy5OeooKNN0 eFB87W5D48LmLccHHOQLKjd9nJQjlJ1K3bWk7g2IekStCm+o+YEl+U8duDA8WXzZuCye Mr4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :mime-version:content-transfer-encoding; bh=9fgLR31T2kJ7ByeAcyeu1jTET3a3Az2KgII9UYX7QS4=; b=S5bFhZGvR2j7SvRMAi17XT5rmvbHndrJcWqT+GkjBnfOCzFK46zA2/FoHuDwOkcWq+ 61nYTeHsALv6SZBLO0aQk+ji/zsKcvT53LZKSEfWoIpkM+UDdYfgGcPt9CFM397txve4 hzIUvM3HTeAaeOCO2gqOSJ6TFy5ge7rtvtnSaSctTLCbO5pnudr5Mk66u1WcUbrzq/cI UP4F7wgZLq2VVqoKnJVOxmTJSEZwubNxcwoy9Tk+VmdqbzLmpqerp/B/44VnZ+jZS3ki 6WmJ1YDZem1crMLWDsu99DB9G8U6gBjn+aJCY4O+EpdH28zScx1gU7WknUgH4XEvPGP8 ukmA== X-Gm-Message-State: APjAAAXU9sKKAa1g4Ap5g99Yu+LrRddAkN7kFCKWhTx1F7rGy9aFSC6V A09uwSNQMnHpbSUsNbwNdh0= X-Received: by 2002:a17:902:7781:: with SMTP id o1mr9466218pll.205.1562913443380; Thu, 11 Jul 2019 23:37:23 -0700 (PDT) Received: from sultan-box.hsd1.ca.comcast.net ([2601:200:c001:5f40:3dac:1a9b:f47c:b78e]) by smtp.gmail.com with ESMTPSA id 125sm11825010pfg.23.2019.07.11.23.37.21 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 11 Jul 2019 23:37:22 -0700 (PDT) From: Sultan Alsawaf X-Google-Original-From: Sultan Alsawaf Cc: Sultan Alsawaf , Jason Gunthorpe , Ming Lei , Palmer Dabbelt , "Martin K. Petersen" , Gal Pressman , Allison Randal , Christophe Leroy , Thomas Gleixner , linux-kernel@vger.kernel.org Subject: [PATCH] scatterlist: Allocate a contiguous array instead of chaining Date: Thu, 11 Jul 2019 23:36:56 -0700 Message-Id: <20190712063657.17088-1-sultan@kerneltoast.com> X-Mailer: git-send-email 2.22.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit To: unlisted-recipients:; (no To-header on input) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sultan Alsawaf Typically, drivers allocate sg lists of sizes up to a few MiB in size. The current algorithm deals with large sg lists by splitting them into several smaller arrays and chaining them together. But if the sg list allocation is large, and we know the size ahead of time, sg chaining is both inefficient and unnecessary. Rather than calling kmalloc hundreds of times in a loop for chaining tiny arrays, we can simply do it all at once with kvmalloc, which has the proper tradeoff on when to stop using kmalloc and instead use vmalloc. Abusing repeated kmallocs to produce a large allocation puts strain on the slab allocator, when kvmalloc can be used instead. The single kvmalloc allocation for all sg lists reduces the burden on the slab and page allocators, since for large sg list allocations, this commit replaces numerous kmalloc calls with one kvmalloc call. The sg chaining is effectively disabled by changing SG_MAX_SINGLE_ALLOC to UINT_MAX, which causes sg list allocations to never be split into chains, since no allocation is larger than UINT_MAX. We then plumb kvmalloc into the allocation functions so that it is used. Signed-off-by: Sultan Alsawaf --- include/linux/scatterlist.h | 2 +- lib/scatterlist.c | 23 ++--------------------- 2 files changed, 3 insertions(+), 22 deletions(-) diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h index 6eec50fb36c8..e2e26c53c441 100644 --- a/include/linux/scatterlist.h +++ b/include/linux/scatterlist.h @@ -310,7 +310,7 @@ size_t sg_zero_buffer(struct scatterlist *sgl, unsigned int nents, * Maximum number of entries that will be allocated in one piece, if * a list larger than this is required then chaining will be utilized. */ -#define SG_MAX_SINGLE_ALLOC (PAGE_SIZE / sizeof(struct scatterlist)) +#define SG_MAX_SINGLE_ALLOC (UINT_MAX) /* * The maximum number of SG segments that we will put inside a diff --git a/lib/scatterlist.c b/lib/scatterlist.c index c2cf2c311b7d..bf76854a34aa 100644 --- a/lib/scatterlist.c +++ b/lib/scatterlist.c @@ -148,31 +148,12 @@ EXPORT_SYMBOL(sg_init_one); */ static struct scatterlist *sg_kmalloc(unsigned int nents, gfp_t gfp_mask) { - if (nents == SG_MAX_SINGLE_ALLOC) { - /* - * Kmemleak doesn't track page allocations as they are not - * commonly used (in a raw form) for kernel data structures. - * As we chain together a list of pages and then a normal - * kmalloc (tracked by kmemleak), in order to for that last - * allocation not to become decoupled (and thus a - * false-positive) we need to inform kmemleak of all the - * intermediate allocations. - */ - void *ptr = (void *) __get_free_page(gfp_mask); - kmemleak_alloc(ptr, PAGE_SIZE, 1, gfp_mask); - return ptr; - } else - return kmalloc_array(nents, sizeof(struct scatterlist), - gfp_mask); + return kvmalloc_array(nents, sizeof(struct scatterlist), gfp_mask); } static void sg_kfree(struct scatterlist *sg, unsigned int nents) { - if (nents == SG_MAX_SINGLE_ALLOC) { - kmemleak_free(sg); - free_page((unsigned long) sg); - } else - kfree(sg); + kvfree(sg); } /** -- 2.22.0