Received: by 10.192.165.156 with SMTP id m28csp404146imm; Tue, 17 Apr 2018 12:08:00 -0700 (PDT) X-Google-Smtp-Source: AIpwx495sYsuwCensFAh4za5mLCOFdsgrA6cKLDbPEXHi/p6WRs9EkrhKn2tfVtYDpxZLQ/GyDeX X-Received: by 2002:a17:902:624:: with SMTP id 33-v6mr3155834plg.361.1523992080103; Tue, 17 Apr 2018 12:08:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523992080; cv=none; d=google.com; s=arc-20160816; b=a0K1MJNHTWY+sdpd7aIo+baxjD81AqsLFUdWzs9GWp12uk1w9MwqCK3ksYcDrcjfYb PoRauCgu1pVjohpDYmzXf6uiNSwUbP6r3uEQjTQyAEcDPyvnsqpflqbGcHTFfJxZc0Rm DhswHf8BFWQSymV6SXnZIVfW3Jh73supVSsfjK2QZrunfu7jJpB6ScEms6YRz/bUYa9I ZGo0CJTkUSkfkOvLUqwFY7HEcQ43qd1Gd1ix3U42C5Wae4iBty47sYZhFeWmHRrOUml3 2knl+pqLBTUHgG3s18Npzrb8aSiUGipBcMsGnvhz5jO9X4UmznkygPn9GMFpcjHKBFU7 ZcKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=2DYutioFCdYxpZklrdh3Xvrr+WvY8dNew+qV8BAaHO0=; b=vxnLQwwZKO/HwECBImpxf+eFagcxEkxHD41iu/BIeaKv/DWytpkNCtQMKBnQg2JpYS zlVbwYhoNE4zVO7BuHjpieqC5LWbCjbq84Gt/F4QX64OpXRkIK4I3ig57JlusAOAjnxh Zig6XtD+Waeyhp/viqqyOWa9uhkbIvf3VEWalBAkFYpB5zpvrsnD2yYoPqWHFd9vHpKs iz3theGHHC/YlioqJvzrAq0ijQAeIe5deZod86jluZW+0hYpBSVjmS1KnAwkK/ZxpO0E MqRK730Bw1pWeBOfsmhXy2B848nPNW8bLO7GSMLMgESL3q4XTnuEA6CdSsAc5UWCzcy1 e4eQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p90si1633195pfj.342.2018.04.17.12.07.45; Tue, 17 Apr 2018 12:08:00 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753170AbeDQTG3 (ORCPT + 99 others); Tue, 17 Apr 2018 15:06:29 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:55492 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752780AbeDQTG0 (ORCPT ); Tue, 17 Apr 2018 15:06:26 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B7133EC016; Tue, 17 Apr 2018 19:06:25 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (file01.intranet.prod.int.rdu2.redhat.com [10.11.5.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6A04B2140624; Tue, 17 Apr 2018 19:06:25 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (localhost [127.0.0.1]) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4) with ESMTP id w3HJ6PXp029570; Tue, 17 Apr 2018 15:06:25 -0400 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id w3HJ6OHL029566; Tue, 17 Apr 2018 15:06:24 -0400 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Tue, 17 Apr 2018 15:06:24 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: Christopher Lameter cc: Mike Snitzer , Vlastimil Babka , Matthew Wilcox , Pekka Enberg , linux-mm@kvack.org, dm-devel@redhat.com, David Rientjes , Joonsoo Kim , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH RESEND] slab: introduce the flag SLAB_MINIMIZE_WASTE In-Reply-To: Message-ID: References: <20c58a03-90a8-7e75-5fc7-856facfb6c8a@suse.cz> <20180413151019.GA5660@redhat.com> <20180416142703.GA22422@redhat.com> <20180416144638.GA22484@redhat.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Tue, 17 Apr 2018 19:06:25 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Tue, 17 Apr 2018 19:06:25 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'mpatocka@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 17 Apr 2018, Christopher Lameter wrote: > On Mon, 16 Apr 2018, Mikulas Patocka wrote: > > > This patch introduces a flag SLAB_MINIMIZE_WASTE for slab and slub. This > > flag causes allocation of larger slab caches in order to minimize wasted > > space. > > > > This is needed because we want to use dm-bufio for deduplication index and > > there are existing installations with non-power-of-two block sizes (such > > as 640KB). The performance of the whole solution depends on efficient > > memory use, so we must waste as little memory as possible. > > Hmmm. Can we come up with a generic solution instead? > > This may mean relaxing the enforcement of the allocation max order a bit > so that we can get dense allocation through higher order allocs. > > But then higher order allocs are generally seen as problematic. > > Note that SLUB will fall back to smallest order already if a failure > occurs so increasing slub_max_order may not be that much of an issue. > > Maybe drop the max order limit completely and use MAX_ORDER instead? That > means that callers need to be able to tolerate failures. I can make a slub-only patch with no extra flag (on a freshly booted system it increases only the order of caches "TCPv6" and "sighand_cache" by one - so it should not have unexpected effects): Doing a generic solution for slab would be more comlpicated because slab assumes that all slabs have the same order, so it can't fall-back to lower-order allocations. From: Mikulas Patocka Subject: [PATCH] slub: minimize wasted space When object size is greater than slub_max_order, the slub subsystem rounds up the size to the next power of two. This causes a lot of wasted space - i.e. 640KB block consumes 1MB of memory. This patch makes the slub subsystem increase the order if it is benefical. The order is increased as long as it reduces wasted space. There is cutoff at 32 objects per slab. Signed-off-by: Mikulas Patocka --- mm/slub.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) Index: linux-2.6/mm/slub.c =================================================================== --- linux-2.6.orig/mm/slub.c 2018-04-17 19:59:49.000000000 +0200 +++ linux-2.6/mm/slub.c 2018-04-17 20:58:23.000000000 +0200 @@ -3252,6 +3252,7 @@ static inline unsigned int slab_order(un static inline int calculate_order(unsigned int size, unsigned int reserved) { unsigned int order; + unsigned int test_order; unsigned int min_objects; unsigned int max_objects; @@ -3277,7 +3278,7 @@ static inline int calculate_order(unsign order = slab_order(size, min_objects, slub_max_order, fraction, reserved); if (order <= slub_max_order) - return order; + goto ret_order; fraction /= 2; } min_objects--; @@ -3289,15 +3290,25 @@ static inline int calculate_order(unsign */ order = slab_order(size, 1, slub_max_order, 1, reserved); if (order <= slub_max_order) - return order; + goto ret_order; /* * Doh this slab cannot be placed using slub_max_order. */ order = slab_order(size, 1, MAX_ORDER, 1, reserved); - if (order < MAX_ORDER) - return order; - return -ENOSYS; + if (order >= MAX_ORDER) + return -ENOSYS; + +ret_order: + for (test_order = order + 1; test_order < MAX_ORDER; test_order++) { + unsigned long order_objects = ((PAGE_SIZE << order) - reserved) / size; + unsigned long test_order_objects = ((PAGE_SIZE << test_order) - reserved) / size; + if (test_order_objects > min(32, MAX_OBJS_PER_PAGE)) + break; + if (test_order_objects > order_objects << (test_order - order)) + order = test_order; + } + return order; } static void