From patchwork Thu Aug 9 20:26:45 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Omar Sandoval X-Patchwork-Id: 10561903 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 EDDC014E2 for ; Thu, 9 Aug 2018 20:26:59 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DAFFD2B9EE for ; Thu, 9 Aug 2018 20:26:59 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CF4052B9F7; Thu, 9 Aug 2018 20:26:59 +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 766E02B9EE for ; Thu, 9 Aug 2018 20:26:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727202AbeHIWx0 (ORCPT ); Thu, 9 Aug 2018 18:53:26 -0400 Received: from mail-pf1-f195.google.com ([209.85.210.195]:34023 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726890AbeHIWx0 (ORCPT ); Thu, 9 Aug 2018 18:53:26 -0400 Received: by mail-pf1-f195.google.com with SMTP id k19-v6so3386317pfi.1 for ; Thu, 09 Aug 2018 13:26:58 -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; bh=Y5AohLxef0EDjlmIDFBw6X6dHuMfsARotcI3MEG8oVE=; b=pKj4IjEZw0/Vx4Rzbw1cBoUpKPV40gduokpmT9LX+9CDhUdGupfC+3OV20pSdL+Gy3 V4v3b1gRQOF1G7RXMoPpUDnWZo1Kbt/DtCSehTsKvNKaYV+DjwbRZw/AghujW2++4caa RYyUSUM+1WpAVkTy8xGy4LbZkdQ217BiBMtbPRN+3miGPENuyVceEJucIM04qGY+nx56 vmPYV38WbHgQ5hW5LGRr099ThFEeldNPI9lsxR8k+bZ0MCk3FCWxo9+azQ7gtv3r50uu L8mIisngsmN9erwiHClWegbEjzv7+30Hl9AuIUGqyscd9GSmA8sObrE8jmU3XlY2rhEL 32eg== 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; bh=Y5AohLxef0EDjlmIDFBw6X6dHuMfsARotcI3MEG8oVE=; b=mSaNE4ep5+YIvSP0bKSAtrZAVNzbuTZ5S2LQbdn1D9BuTyn8wnw97c8jUBAfu3s/hZ s3yDpssDcIlw5nFesds9bTCyhngMD/d36cP5XR211eRaP499/CD2BvVqXKS0/LsMCwQM pz8IO3EpjwAe7hYQ6Jkf+DYuREGqzHR+y7A0DVzeGU6Ev/h0O0dr2r2g1lX5r0rBywb3 neRuvT17Hk3ntmnz2ucMYs7z8fKjpuYiQouQ/4vKuE01sxWh1avg/uriJK7oRNHbjdFT WGitYJzMlxn3zAgTKqdyzP2poWdUwe26CmevNbw/1iO7qV+jxAnF5Bbypg8ipyZ5s+wP nTlA== X-Gm-Message-State: AOUpUlEQg+KFn0uiEGPErSiboWGKK8yZbXOj/YpurEg87umNN6j8Z+6M sdoMqx1oVomO88NA5V1g8WOdRl2+/as= X-Google-Smtp-Source: AA+uWPz6/RwmkK8EL6YPjIOGhhC32akgVjqc4luQxQsqvQztDSPpCnj+Z4rwF7TqDB558AIP+81kbw== X-Received: by 2002:a62:d113:: with SMTP id z19-v6mr3835126pfg.98.1533846418029; Thu, 09 Aug 2018 13:26:58 -0700 (PDT) Received: from vader.thefacebook.com ([2620:10d:c090:200::4:dd24]) by smtp.gmail.com with ESMTPSA id u2-v6sm9841709pfn.59.2018.08.09.13.26.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Aug 2018 13:26:57 -0700 (PDT) From: Omar Sandoval To: linux-block@vger.kernel.org Cc: Jens Axboe , kernel-team@fb.com Subject: [RFC PATCH 3/5] kyber: don't make domain token sbitmap larger than necessary Date: Thu, 9 Aug 2018 13:26:45 -0700 Message-Id: <47e82117e82563637b9a7091b827267f6874b9d2.1533846185.git.osandov@fb.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: References: 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);