Received: by 10.213.65.68 with SMTP id h4csp488697imn; Tue, 13 Mar 2018 10:38:16 -0700 (PDT) X-Google-Smtp-Source: AG47ELu6ys+exhCpeRHtGVeSd5jDqTvWYyvuZ84gxH18nl8cL13xEg+8U5ERVFUfEElCyWTH9smX X-Received: by 10.99.107.1 with SMTP id g1mr1137049pgc.347.1520962695889; Tue, 13 Mar 2018 10:38:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520962695; cv=none; d=google.com; s=arc-20160816; b=YLhdZWSYh8ajdY8qCodCIVGaV4ZEkQvhSIXAv8/r/5fwqlLGU9q8wtT8QjptXbs1Er 31vGZm9+EiUBR1JUAgrufQnJjmK/SSP9dAaC6yLA+WbOoCR0A0ZtpWCyPdCpRIhJKQRj uutyWNO9KcgUUAQJGqAyvdz1h2eIOBd1LXhobDHKyr+9S71QnizvlA6dDt0qCO8SgsfE Z2u387R12KjaXrOWHaiQlufFrO2JcR1qHPIZoM6LO9eFIEUz8atdDS/AjPlBv4IOdEbF Q7TVlWu3K64EXQ3FM/ousVi/nosgo3gY0GgzImmjXF+SFdBxYDqEHSlpR7DG2Hx/C/Oc kpWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=LWm+l8NQYT+PkuK/SKsmYjBXD2yoNR0nBjnMQO1y/e8=; b=P2x2dfpetMI2rtwcVBG36I0QzHE5QtX1oObNTh+PgDY6GIpPyCdj8JZObnDNEqTku+ I7l74gb2FXm44Nq+ZxB5TZxrtVO/zLwz0Rh6BAzwLlTLZBrpLYDpl7hRIMHq/CxEK/XH oi8cEh0DHNQHQ3IFR3SquYbvsEVhW/sKrVArn+kIMFEf1LahLjQzL/29A1ZQ++R8ydkX FPD0OPeY8nmdS/sHtVN4m1gHkA+pRCo+sc4FaHbnUdF/zXLBBP21w7Z1E93USdGjlgsI cW6S2uBWdX5SrqXgv/RQElbIGBBQUJTyDKnQrOQ2O0khe/uHnIrIdV5D4EW1B43RwVIM vQgw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=NmVCaH6S; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g11-v6si437283plt.580.2018.03.13.10.38.01; Tue, 13 Mar 2018 10:38:15 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=NmVCaH6S; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751806AbeCMRg4 (ORCPT + 99 others); Tue, 13 Mar 2018 13:36:56 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:43390 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751412AbeCMRgz (ORCPT ); Tue, 13 Mar 2018 13:36:55 -0400 Received: by mail-wr0-f193.google.com with SMTP id o1so1168787wro.10 for ; Tue, 13 Mar 2018 10:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LWm+l8NQYT+PkuK/SKsmYjBXD2yoNR0nBjnMQO1y/e8=; b=NmVCaH6SFYMBWr2igmG2CYu7fJuMTnS4qboyTWiQcVZU9W3xkp2HHSiIAN0xWo2KPG JjL1XkHUrdVlZeB/br3yBvR37TRGHED+Rv/KP8oUe+TOtLnhA1Tn0NVcX6hB+PBjm+Gy tcMujywgQ1PosP1OIeIke7BtIW6p2K2CYmgQI/CB4npzO3nwEY50O+6N4irhmZ61cbG/ /I7rajeOj/1G+FlD6tGGzUAdnY4ihqnLbrGOs3HG/8QAU7TlgIgqAHaYwYtvF6EAb3OS IHCO7uA0OuqrK3MjoLOCgjU4HS9VBLiXfFJ6iSKQaB4io0NNjLwm60dNlORFighnX0cM 6ScA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LWm+l8NQYT+PkuK/SKsmYjBXD2yoNR0nBjnMQO1y/e8=; b=sZIZGD1gmfcxbKSj+fm0HxAksRVg6isMhWV9esycJz+/wmLzRTNn9F/TaDUzO414aE P49r5zYGaFgEEw0wp1HRvXEAugD5TT7AH6rthPg/AOcjJutJj0M+U0kInjlQ8Eb3ux6d gU5ikP2CgXCSqOp+QFJWiwS0Tb6kzXPPxTTYAXvVw1aUfphjfQDfpbziH4BXoFW1lP+n 8aydZrZTtb1q1l2NTetFNy4DBafA3opC5L51gFGsMRJvQku7LTsKL1Fg84S/BxulISYP 8Uq2BqZlpV43VpHTNmSPt0IjI/DT3eBZp+Q61bpBftVZZPaILr0mVy6vksqyGLM3mFtu 1HYA== X-Gm-Message-State: AElRT7FYNaIfwlqpGseLkfNtY4VBYVa7LjIkj9UTyNBzAS4LZf5MPc5Z A34iB6JaFJR9ju+OmGbm1T7sWYrLeYVFUk9mhhzhzA== X-Received: by 10.223.209.202 with SMTP id m10mr340465wri.99.1520962613738; Tue, 13 Mar 2018 10:36:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.184.12 with HTTP; Tue, 13 Mar 2018 10:36:52 -0700 (PDT) In-Reply-To: References: <20180313165428.58699-1-shakeelb@google.com> From: Shakeel Butt Date: Tue, 13 Mar 2018 10:36:52 -0700 Message-ID: Subject: Re: [PATCH] slab, slub: remove size disparity on debug kernel To: Christopher Lameter , Vladimir Davydov Cc: Suleiman Souhlal , Greg Thelen , Andrew Morton , Pekka Enberg , David Rientjes , Joonsoo Kim , Linux MM , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 13, 2018 at 10:19 AM, Christopher Lameter wrote: > On Tue, 13 Mar 2018, Shakeel Butt wrote: > >> However for SLUB in debug kernel, the sizes were same. On further >> inspection it is found that SLUB always use kmem_cache.object_size to >> measure the kmem_cache.size while SLAB use the given kmem_cache.size. In >> the debug kernel the slab's size can be larger than its object_size. >> Thus in the creation of non-root slab, the SLAB uses the root's size as >> base to calculate the non-root slab's size and thus non-root slab's size >> can be larger than the root slab's size. For SLUB, the non-root slab's >> size is measured based on the root's object_size and thus the size will >> remain same for root and non-root slab. > > Note that the object_size and size may differ for SLUB based on kernel > parameters and slab configuration. For SLAB these are compilation options. > Thanks for the explanation. >> @@ -379,7 +379,7 @@ struct kmem_cache *find_mergeable(unsigned int size, unsigned int align, >> } >> >> static struct kmem_cache *create_cache(const char *name, >> - unsigned int object_size, unsigned int size, unsigned int align, >> + unsigned int object_size, unsigned int align, >> slab_flags_t flags, unsigned int useroffset, > > Why was both the size and object_size passed during cache creation in the > first place? From the flags etc the slab logic should be able to compute > the actual bytes required for each object and its metadata. > +Vladimir I think it was introduced by 794b1248be4e7 ("memcg, slab: separate memcg vs root cache creation paths") but I could not find out the reason.