Received: by 10.213.65.68 with SMTP id h4csp1118333imn; Wed, 14 Mar 2018 10:06:22 -0700 (PDT) X-Google-Smtp-Source: AG47ELvkP0/t6GmWzDEk/su5ApLtEDKJwhb+BS6BXS0Gr2945TMa+adXHyQYEuzlzp4AO2PtGpRJ X-Received: by 10.98.64.73 with SMTP id n70mr4973793pfa.142.1521047182196; Wed, 14 Mar 2018 10:06:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521047182; cv=none; d=google.com; s=arc-20160816; b=RDPrdoY/rHvzABREbBQHRAL+TnyKY6t6f+YRo0bssDfmu932mKpotjJJezrEVtBX1t lUE75uLdy6NdmCq/RXcg9DWI+ev8HiABmoJ63S5u0CI8oqazUiJBXNGtIUFeYbyq3+k0 xL5HpdlVuShSWUBWhpCiD2KfHTie0ssoog1FqYou2uFb8iErmzrF4ubtHyLeyQTBZgDF KHrnkuXJIpMyjUVH3FSp1yHB39pF67PrODkULr9FT83e0Qdb1R562PNWg4FqIAjdtLK1 kOO9KmBU5z+HNi/incBUfC+rjFEc/e3uNrk14D2W5UbyT1xGnHGfT98I5QwJwFna5SoC 71CQ== 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=D6waGSE7AGltyLS3DhkSFK+CUvDWjL56a8Po2OwLHDI=; b=QSnBe1+b5UmGI5bWVTf45HBioDZWX0HvyFUAUUd5XtoslOjZEXYcZrupQ6m8+A24QT g6XDFiI2BFsjwCcouCIRN9mjBPBD9eJGSvOg+0cxQbbdBzCk1e2ECJqQXo8pZs4qzqgw POccu/lnQG519OVLsG1RCzWs/KRUM7RyH4mwEmpy58vdsx80iHjT9DCR/dKjvrHMcC0+ HDkB1oMhUgb87uW6RHoC9VHIJo1KwMZ3JVc6annYwzmetAD9sP9ORpnYUHMYftqg1l/W xt2klFTMw3qFMqSlBT8PGllz03/3A6kXK/cmHwSEAvIDYWpx+unOpesVWfP2k5k63r4G l+pQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=kr/bkuvo; 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 3-v6si2249018plx.463.2018.03.14.10.06.06; Wed, 14 Mar 2018 10:06:22 -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=kr/bkuvo; 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 S1752407AbeCNRCg (ORCPT + 99 others); Wed, 14 Mar 2018 13:02:36 -0400 Received: from mail-wr0-f195.google.com ([209.85.128.195]:42936 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751408AbeCNRCd (ORCPT ); Wed, 14 Mar 2018 13:02:33 -0400 Received: by mail-wr0-f195.google.com with SMTP id s18so5460908wrg.9 for ; Wed, 14 Mar 2018 10:02:32 -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=D6waGSE7AGltyLS3DhkSFK+CUvDWjL56a8Po2OwLHDI=; b=kr/bkuvo7KZpQtcPooxoWmg4n96LEnvgKFDutU7LYXSJiUkNaxIhYRSXzhJl+2AZEZ yiUlyg34AbEYc5zWOznskxjs8ZVbpysXr8b0rvZwH/1ZpwtV07ZM6Kk3pdq6kuiLSV/V tV6XKDkmE5WTkWz536YG9CrP4mC9PZvCDSj9ZSgiL1Se8MWujg5iNXh/vRWblY2OHJ+7 Oj2BsfX144IkF/vquj7v56qToaq95oFcgqg5plunlM1w8BTOUZrPKvc8gbbjLZuficNP ZEo/9M8UwHH8kTGw9sb/8ftTYGOL2gHn4C/qsr0G5tgSLelkpNMzS/5ezoe2IMNSNRet r1sw== 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=D6waGSE7AGltyLS3DhkSFK+CUvDWjL56a8Po2OwLHDI=; b=im/AfDcs0fYJWWU8Bma5HsiHMVhFhND0dN0cZkHJgCiCz2gCbymL0vMMaGoGHQObsE dlz4OFFE1eh+OzJ2o6SB0gm1vBf8YUJXFE7yynsOCdS8Q+lG4tY7uk4UQfhRJpimyMWg 75wY9MDLvV9dVFu6NzwWelEcw36bGQ5sAynVQfMkY0sp8TjRkKfC+0Fbkrux5qor0GEW NE1/ewnyMgwr2YAyJ86PgwUtRBde1VjUlfjrtE6z+78dwnrf94glAZIoL+8PPFQVnoTo MvhIyMWYfDbWdXCy3aGfKXAyP0BDHWDoXpPTjpR2XX2fdJoYVGOrvReESHHReznnSJfS Ky9A== X-Gm-Message-State: AElRT7HqJHmia6tpBNO450qnlJX6G38cLkh3fXJT+FAL/P6eZdsjdic4 0T6V/Zr7U+PAU8EaLbMbIH/v9Hv6Dlnu2xZM0V81xA== X-Received: by 10.223.209.202 with SMTP id m10mr3328831wri.99.1521046951689; Wed, 14 Mar 2018 10:02:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.184.12 with HTTP; Wed, 14 Mar 2018 10:02:30 -0700 (PDT) In-Reply-To: <20180314084329.y7735ecw2is5i5pd@esperanza> References: <20180313165428.58699-1-shakeelb@google.com> <20180314084329.y7735ecw2is5i5pd@esperanza> From: Shakeel Butt Date: Wed, 14 Mar 2018 10:02:30 -0700 Message-ID: Subject: Re: [PATCH] slab, slub: remove size disparity on debug kernel To: Vladimir Davydov Cc: Christopher Lameter , 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 Wed, Mar 14, 2018 at 1:43 AM, Vladimir Davydov wrote: > On Tue, Mar 13, 2018 at 10:36:52AM -0700, Shakeel Butt wrote: >> 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. > > This was a mistake - I missed that __kmem_cache_create() overwrites > kmem_cache->size. Thanks for fixing this. Thanks for confirming. Andrew, can you please add following line to the patch commit message. Fixes: 794b1248be4e ("memcg, slab: separate memcg vs root cache creation paths")