From patchwork Thu Sep 27 22:55:53 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Omar Sandoval X-Patchwork-Id: 10618723 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 57250913 for ; Thu, 27 Sep 2018 22:56:35 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4AB292B561 for ; Thu, 27 Sep 2018 22:56:35 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3F0302B56B; Thu, 27 Sep 2018 22:56:35 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D6B612B561 for ; Thu, 27 Sep 2018 22:56:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726100AbeI1FRL (ORCPT ); Fri, 28 Sep 2018 01:17:11 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:38830 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725957AbeI1FRL (ORCPT ); Fri, 28 Sep 2018 01:17:11 -0400 Received: by mail-pf1-f196.google.com with SMTP id x17-v6so2908822pfh.5 for ; Thu, 27 Sep 2018 15:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=VjltX173hApTc7hUXh4zTpNOr3tihINNCf28/dpEECs=; b=eRHRzUh1mvUIJ6aAkDYB/12U1A7UgSTvtjjMWTnYuWnFgaNCW1pYmWHR3Y8o+sE1/+ MrZLsbTBsFBernrIB/HouXtWkBHxYVe+wgkEwhyrIG8h6mcM08OMg5LhoJadyUAeDcL+ GPZVbpyyUxe6EoiKYJ7Wo6y/+uG3k1Lb+pgfmUI3XSgP12lDQkGypATQIdeTGnHYYced zHlIGwXisjnglJAXmFaLdSkaKpBY6xhABGIohuS7oBTKq/Z/IBgvjGsonSG0nTHMF5Ln dTYAT11GxCZ/sTUQo+8hKBhOIGCW8AzYhHpq5IOzA+CP9t8IdEUdM+V+n3nwToY7QZ2l eQrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=VjltX173hApTc7hUXh4zTpNOr3tihINNCf28/dpEECs=; b=GyEpUujPedRur5sDpl5w+uoFnmdtBPBVGq77cQ5aRRMvYHsuMgAynJu1c1DMdQlfrD V8KcGVQq1t9gu2was2zPn0j3e3B6TMYS23dg29NugBQvjiSEpS4BwpWg0VHvk99zi+dX si0xRxJ8tbzwLI6zWuAq6Kss9wqylDB/RPK+3KCD0Dlx/ucR1jWOeg83KiT+8FuGXB1N CBg8Ci5brEYg40JJKpg4dSymZlfzYGFl0OoidGKiqKdymCt6GA71XRYTVCnMo0hPH5l3 BChRzXaxc7p6uQgWqzsqL27Nom9hARDYiLZRDRCuMOlrhyf6RMFmM5OUDbymbFIyBQlO b3jw== X-Gm-Message-State: ABuFfohG7vZIwptAu4+/zvcud8Rc/pKXxr6Pk6kr3RlAp+IxvFQdfZW2 z5RllAovtOOA/AiXpZjDnrI17GGbENc= X-Google-Smtp-Source: ACcGV61pWVy8+WUMhtAe3Oyac5jSBUf8Sj4sqha0T/ZMx8ryoQ3lRzjOV9Aut7fiiikBbj3RCl/ZUQ== X-Received: by 2002:aa7:824d:: with SMTP id e13-v6mr13614012pfn.97.1538088992547; Thu, 27 Sep 2018 15:56:32 -0700 (PDT) Received: from vader.thefacebook.com ([2620:10d:c090:200::5:3e64]) by smtp.gmail.com with ESMTPSA id t1-v6sm3716721pgp.32.2018.09.27.15.56.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 15:56:32 -0700 (PDT) From: Omar Sandoval To: linux-block@vger.kernel.org Cc: Jens Axboe , kernel-team@fb.com Subject: [PATCH v2 3/5] kyber: don't make domain token sbitmap larger than necessary Date: Thu, 27 Sep 2018 15:55:53 -0700 Message-Id: <22c03a0be5e385516b9c2b2cb37c3baa54e82129.1538088475.git.osandov@fb.com> X-Mailer: git-send-email 2.19.0 In-Reply-To: References: MIME-Version: 1.0 Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Omar Sandoval The domain token sbitmaps are currently initialized to the device queue depth or 256, whichever is larger, and immediately resized to the maximum depth for that domain (256, 128, or 64 for read, write, and other, respectively). The sbitmap is never resized larger than that, so it's unnecessary to allocate a bitmap larger than the maximum depth. Let's just allocate it to the maximum depth to begin with. This will use marginally less memory, and more importantly, give us a more appropriate number of bits per sbitmap word. Signed-off-by: Omar Sandoval --- block/kyber-iosched.c | 15 ++------------- 1 file changed, 2 insertions(+), 13 deletions(-) diff --git a/block/kyber-iosched.c b/block/kyber-iosched.c index 95d062c07c61..08eb5295c18d 100644 --- a/block/kyber-iosched.c +++ b/block/kyber-iosched.c @@ -40,8 +40,6 @@ enum { }; enum { - KYBER_MIN_DEPTH = 256, - /* * In order to prevent starvation of synchronous requests by a flood of * asynchronous requests, we reserve 25% of requests for synchronous @@ -305,7 +303,6 @@ static int kyber_bucket_fn(const struct request *rq) static struct kyber_queue_data *kyber_queue_data_alloc(struct request_queue *q) { struct kyber_queue_data *kqd; - unsigned int max_tokens; unsigned int shift; int ret = -ENOMEM; int i; @@ -320,25 +317,17 @@ static struct kyber_queue_data *kyber_queue_data_alloc(struct request_queue *q) if (!kqd->cb) goto err_kqd; - /* - * The maximum number of tokens for any scheduling domain is at least - * the queue depth of a single hardware queue. If the hardware doesn't - * have many tags, still provide a reasonable number. - */ - max_tokens = max_t(unsigned int, q->tag_set->queue_depth, - KYBER_MIN_DEPTH); for (i = 0; i < KYBER_NUM_DOMAINS; i++) { WARN_ON(!kyber_depth[i]); WARN_ON(!kyber_batch_size[i]); ret = sbitmap_queue_init_node(&kqd->domain_tokens[i], - max_tokens, -1, false, GFP_KERNEL, - q->node); + kyber_depth[i], -1, false, + GFP_KERNEL, q->node); if (ret) { while (--i >= 0) sbitmap_queue_free(&kqd->domain_tokens[i]); goto err_cb; } - sbitmap_queue_resize(&kqd->domain_tokens[i], kyber_depth[i]); } shift = kyber_sched_tags_shift(kqd);