Received: by 10.192.165.148 with SMTP id m20csp2498104imm; Thu, 26 Apr 2018 12:02:34 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpJDQ16jdA4t/twJhOrCTIOM8Z5K4j5OCqjIqm1qJp8nu8fIjRQLZ2RyYuhxWNHm7r4tG/e X-Received: by 2002:a17:902:688e:: with SMTP id i14-v6mr2175245plk.391.1524769354512; Thu, 26 Apr 2018 12:02:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524769354; cv=none; d=google.com; s=arc-20160816; b=JOG7D/Dibl0TmLYLx66HbaNo5KtKu8pec+K1Wr7+ha+IZ7qS148KQjkg1wewSZP2KL L9AF/DZKZ97T0pMkmdiaHHlrrcuOfsyFDt9L26goIDQqCqisAGEZO/5bS6ZsSQHnmi5C k75aLA+ucen3MD1IaycI5ZL0sXGOjeLgwHtjaisZy0e1/uokb2FhHlMBFi2E7J9olf3b 3IPctLg9bRZiQ9Qr2ihU7Rl7d3DyER1h6KCjFi8CIg0Hmo8a3r8r21VyhlBya7q/aV3Y jCHuyyhUm26Pg8omMstQSpFL0hAkpE8qUxOaJuV6Zj3kQiV4sRCxInYo4CTTllEreWJ+ E8fg== 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=TOrgrS9nbRmnUBEHl0cHKOZp4Bb+Gngipg4n1WBNkWY=; b=B5Y8U8lTw7edj/EYYe3VQ1YfKL81NHwCt/q0gOwWeTe3wCvWLjUE3S1aEglDaDDdjM 0e7OLz/5DmCw2T155Ueef6hvBl6BgThQbW0s1ZbsYt9kb/SIpEMp1PjZmTRC62ZZRJul rzlHDzc03bneTasBRaQT/YBBNeS+fKq0VaRRcsDVCNe3humpesayBVrxbOcsb0Q1OuNB gjqglcNL/OWjrXOAVMPHqajneWoffjHcByXOrwJgKx1DQ9ubcANyTIIbTPpsOpnHRIYq +7uQM1K60lHLVMolpxpIpScY9oIMz2wziKZ4qJQpvlghARcIdqttVvonlPWpy4hqLM1M FsPA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f8si16483805pgr.419.2018.04.26.12.02.19; Thu, 26 Apr 2018 12:02:34 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752000AbeDZTBJ (ORCPT + 99 others); Thu, 26 Apr 2018 15:01:09 -0400 Received: from resqmta-ch2-11v.sys.comcast.net ([69.252.207.43]:44080 "EHLO resqmta-ch2-11v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751128AbeDZTBH (ORCPT ); Thu, 26 Apr 2018 15:01:07 -0400 Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id BeQafY2uwqEz4Bm8hfHo2T; Thu, 26 Apr 2018 19:01:07 +0000 Received: from gentwo.org ([98.222.162.64]) by resomta-ch2-19v.sys.comcast.net with ESMTPA id Bm8gf0MEN3rorBm8gfGHmC; Thu, 26 Apr 2018 19:01:07 +0000 Received: by gentwo.org (Postfix, from userid 1001) id 6F8131161690; Thu, 26 Apr 2018 14:01:06 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 6D0DF1160356; Thu, 26 Apr 2018 14:01:06 -0500 (CDT) Date: Thu, 26 Apr 2018 14:01:06 -0500 (CDT) From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Mikulas Patocka 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.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CMAE-Envelope: MS4wfFhw0NcBtSZELLVtU2zw7fG1G1fihAClbsw5cnuXoBZznAUV0kLor5TRforWpw/ItJfzgfNVNcW6dG1SI5R0RG6PJeFfQIh4ywRhtXMUFmVbGsPt1lVd GdQjxhxofIBE7n0VUt+CYSZ7S/cnRV4MZWDlEN3SX6qt1f9QKV9mgQ63IB2D4jlEWU1S9LM6nRwhYVPUVlfSDurqLAAtW4v3kTU7weXmwGofJqBlJ+OBhd/s lpI0rXOb+rwvKKKMRuN3JF/sjcM+65qm2rQBAvgDng007EUBK7TjWjHtabob8S266CsWkj/BxTAyhK0HIqmXTmhubXcrKP383upl3NiZ7DJ8AD5LOxA9VCM+ QDogp6OHtpSsE7NYMYW+NqZqswwe6x2NsALwfOtRPIbOqAF2FVFJ47vmUDv/AEyy8avQ/a13qFrkHfswL8FXMC7N+2yqvaaWVGA9TPzzLC+YvHfQ3WGVdYjG OW6GZVheSYfzDU6c Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 25 Apr 2018, Mikulas Patocka wrote: > Do you want this? It deletes slab_order and replaces it with the > "minimize_waste" logic directly. Well yes that looks better. Now we need to make it easy to read and less complicated. Maybe try to keep as much as possible of the old code and also the names of variables to make it easier to review? > It simplifies the code and it is very similar to the old algorithms, most > slab caches have the same order, so it shouldn't cause any regressions. > > This patch changes order of these slabs: > TCPv6: 3 -> 4 > sighand_cache: 3 -> 4 > task_struct: 3 -> 4 Hmmm... order 4 for these caches may cause some concern. These should stay under costly order I think. Otherwise allocations are no longer guaranteed. > @@ -3269,35 +3245,35 @@ static inline int calculate_order(unsign > max_objects = order_objects(slub_max_order, size, reserved); > min_objects = min(min_objects, max_objects); > > - while (min_objects > 1) { > - unsigned int fraction; > + /* Get the minimum acceptable order for one object */ > + order = get_order(size + reserved); > + > + for (test_order = order + 1; test_order < MAX_ORDER; test_order++) { > + unsigned order_obj = order_objects(order, size, reserved); > + unsigned test_order_obj = order_objects(test_order, size, reserved); > + > + /* If there are too many objects, stop searching */ > + if (test_order_obj > MAX_OBJS_PER_PAGE) > + break; > > - fraction = 16; > - while (fraction >= 4) { > - order = slab_order(size, min_objects, > - slub_max_order, fraction, reserved); > - if (order <= slub_max_order) > - return order; > - fraction /= 2; > - } > - min_objects--; > + /* Always increase up to slub_min_order */ > + if (test_order <= slub_min_order) > + order = test_order; Well that is a significant change. In our current scheme the order boundart wins. > + > + /* If we are below min_objects and slub_max_order, increase order */ > + if (order_obj < min_objects && test_order <= slub_max_order) > + order = test_order; > + > + /* Increase order even more, but only if it reduces waste */ > + if (test_order_obj <= 32 && Where does the 32 come from? > + test_order_obj > order_obj << (test_order - order)) Add more () to make the condition better readable. > + order = test_order; Can we just call test_order order and avoid using the long variable names here? Variable names in functions are typically short.