Received: by 10.192.165.148 with SMTP id m20csp1187498imm; Wed, 25 Apr 2018 14:07:31 -0700 (PDT) X-Google-Smtp-Source: AIpwx48ISXl7OR0nAJnF8jY52PzdUPBk9CRsvyn+sNcA79wG3zyy3if1OMaij6DeUZrZEPsnFqyI X-Received: by 2002:a17:902:6902:: with SMTP id j2-v6mr30240953plk.92.1524690451720; Wed, 25 Apr 2018 14:07:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524690451; cv=none; d=google.com; s=arc-20160816; b=wgcEv/nxGpSyLJxV/AwCbvy1v4Jl0kk4kMUp5NtYFM4VwMxdpNnc35N+QG+ArmdArB Hy1B8VbB3/ahX5qrVJYC589Htdb69sCLcXlNG5qq8jZHD4WbS4vnKWdBSFhSqoZZhjpd OweGuXd+qUSNAqI8O4uAaJ/6cM99FsAdgt1p8aeUIR9VVDbZ5y+HM1IpwhRFGlDkmxrv qzpQ70OJwjH1g+/suC8IUzDKeI6SE+9MsOVi01sDDnSjU6o7236noYZffyzzxZZNFmeK m2gTozss2zfeyRfmh2V8fyqZoKrkvr+iRby8fcreF0pd4vbOdISmqazyiwPmPG+sxObJ iqKg== 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=nvB49Nri6+oWuGgxXM+8NuW6vPO7bctUwpDOAp2ST9Y=; b=XoZlxhAuPQT4hQtNfZ5fIwAIg8XMhRkDnoxhI3xjGtZ0C7EJxO/tQBGlD5bqDDra94 Y12GpXzUB4SD8yDpLghqkIb65praFn+AaF0B+ctAU0ucXQaXxzmNyHToU9sQKmq6RaGx z0CRgctPnJ+yRcaX/uKjLBzD1KmWYV84cm2ra9S8F7/zYUbqZhgcR7ETcLP/heVS9VAa /dHq0neLiYSTdOysfrthXVvXwCBUt69LRiYzTal82HmbWNCZAN93jbM7DjogsKbi7luQ h4OwcWIXkXQyCQxNKavZBuEhdAU4k3Nkufvro3MPR+KDQUaFci8zz7QJGp1M04llVqly nwJA== 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 66si16953895pfm.167.2018.04.25.14.07.17; Wed, 25 Apr 2018 14:07:31 -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 S1752614AbeDYVE6 (ORCPT + 99 others); Wed, 25 Apr 2018 17:04:58 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:44610 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751558AbeDYVEz (ORCPT ); Wed, 25 Apr 2018 17:04:55 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9FF8FA2C62; Wed, 25 Apr 2018 21:04:54 +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 A1F4D1DB24; Wed, 25 Apr 2018 21:04:50 +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 w3PL4o1r011466; Wed, 25 Apr 2018 17:04:50 -0400 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id w3PL4nIP011461; Wed, 25 Apr 2018 17:04:49 -0400 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Wed, 25 Apr 2018 17:04:49 -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.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 25 Apr 2018 21:04:54 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 25 Apr 2018 21:04:54 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.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 Wed, 18 Apr 2018, Christopher Lameter wrote: > On Tue, 17 Apr 2018, Mikulas Patocka wrote: > > > 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. > > Well again SLAB uses compound pages and thus would be able to detect the > size of the page. It may be some work but it could be done. > > > > > 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); > > The slab order is determined in slab_order() > > > 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; > > Could yo move that logic into slab_order()? It does something awfully > similar. But slab_order (and its caller) limits the order to "max_order" and we want more. Perhaps slab_order should be dropped and calculate_order totally rewritten? Mikulas