Received: by 10.213.65.68 with SMTP id h4csp848436imn; Wed, 14 Mar 2018 01:44:41 -0700 (PDT) X-Google-Smtp-Source: AG47ELv/ggX6u5SZOFQP1HjlmwXLwqzoRP0upGATZUGUeXgIguz45Jeiofp+Av5+UHQuW6LkdKs/ X-Received: by 2002:a17:902:6ec5:: with SMTP id l5-v6mr3311886pln.113.1521017081600; Wed, 14 Mar 2018 01:44:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521017081; cv=none; d=google.com; s=arc-20160816; b=Q6CGuNG57bvTu5H7FlOv4unff1Ev8EHraBVXltyKeSTNrDsrLCHJtb/kPlmgIeVXzF ltIpHzUZw5vdNcW4nBAPjyFDiR+Kt4ejIWvy2UUykZHN4jyz/NkukS8gwex7nB2fh7IC YPRpc2vH3RuvkZOUFYclR81VOARkKhH4LXx5h7GC/7zTzTZRhNd4P30ttGWW5+QDUC/8 V4wvWCJcSjrh+YkvqpIoFRkkzgq4br5BGppl16Y6FZ0a7ocBHiGN8uwZN+kCwYnscRz9 qPZ0H8zPg882eVS83q43bPN9gR4yl73zhqQUA5pSO29ivO3qfRLubW4XjPkuK3yKP+SG pajw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature:arc-authentication-results; bh=99I1at0rPsFLZNYuDg70Vv94kz4Qbo5Dz8AzKyrQ+4o=; b=VHXqSCuljw/KYYkdvup31LqMtH5FpDFDlrt64mwYUJFaZbReb65KgOX8wdASnB8UFP kwjPHpivmr42hr07oYKAGc708y3b9Kh244ZWlYjmHXnZObMcGhrEejZ266uAtygSIFR8 1xH/5bUT3Nm+N35ZlB8kmTIKDu8H8g79RAS+I1r3TXfusXs01B+NxpPvpMiVRp8fp4hT 1xYZ3Gq+i/fL7eUveq8Hpdm3sdcldOwj0MkWS++8Tzq2gNepbUHW8hLK3BGS7KlsSrCM oRXOrKkLIhV2t9NGeQjZYjO2q4wlMp53o0qknJFr6nKIFcv6XG5qwTBCQ1h7nPTlMG/V dUtw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=A6VreBpf; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ay8-v6si1601916plb.554.2018.03.14.01.44.27; Wed, 14 Mar 2018 01:44:41 -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=@gmail.com header.s=20161025 header.b=A6VreBpf; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753190AbeCNInf (ORCPT + 99 others); Wed, 14 Mar 2018 04:43:35 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:35980 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751228AbeCNInd (ORCPT ); Wed, 14 Mar 2018 04:43:33 -0400 Received: by mail-lf0-f67.google.com with SMTP id p74-v6so3533781lfd.3 for ; Wed, 14 Mar 2018 01:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=99I1at0rPsFLZNYuDg70Vv94kz4Qbo5Dz8AzKyrQ+4o=; b=A6VreBpfNt91Y7W5OJxlOddlF3i20i8LvfdM64/PNrl5JAtnpTYiArVabdC+BxYSWw OHOVQ3eRGOqhaenwpXKTXs+LeYikcrOJYgpWhaY4EP3X6H+GpJJEOaVtlPVKObUO1Xdz mTcjjc6Hf9hxBvnajEtbsz7UdN/dPa2u1oQhbO8sBIfpRyKD4S2JSW0VrSLk3EEerkKx AES9rgrH99/K4sYix3OK4WZ76nZgONjQZ4sk2orqmXNPpv5PO1gEF+D7Y2Ljwj4YKchk 5sHDgzS8h315pAyqoqSquNs6ZXDKW+tXTSYTqF2fbXg9qO9WHHkHvoQ7On1mfEAuJ4Yp zMDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=99I1at0rPsFLZNYuDg70Vv94kz4Qbo5Dz8AzKyrQ+4o=; b=DYMIyXMJP0u9AYKMvrj+vl1GlAU7s7MAoa9cLESOprdH7qxX+uEg1tT7+NIGMaTBDX pir3Zwfo/F9NbJ3jUieEPtMy5DK8v1zY0K6kn9GHDaO+xxkVTVWqUwTMLgxMMAhIpD1j AlDvI5CoHkvZ+f6/m/kxEx45FDO410F1JLFuqJ9lFcywx7VQZhuD3rG9vu83Xna/HmM4 OcLbyp9XdE5dh85w0y024Ub29bPGpwvXtD6e46Z1csnA8vnn31FJySwQ7swX/pF5mIIk 5Z34JMGvbxkXjSCHARIphH5ZnlMqMNbaf45RYH5GuLww60MdBHItrZA/idcPrSUv0AtM VjkQ== X-Gm-Message-State: AElRT7G4GrO4RZhqaHzjDYKA8rTYvDyqSy7ahBDvVqKMy3vfcguJac9i FaC9fiS/wADFwW0HLknR0EE= X-Received: by 2002:a19:258b:: with SMTP id l133-v6mr2839335lfl.70.1521017012491; Wed, 14 Mar 2018 01:43:32 -0700 (PDT) Received: from esperanza ([185.6.245.156]) by smtp.gmail.com with ESMTPSA id n5sm329367lje.15.2018.03.14.01.43.31 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 14 Mar 2018 01:43:31 -0700 (PDT) Date: Wed, 14 Mar 2018 11:43:29 +0300 From: Vladimir Davydov To: Shakeel Butt Cc: Christopher Lameter , Suleiman Souhlal , Greg Thelen , Andrew Morton , Pekka Enberg , David Rientjes , Joonsoo Kim , Linux MM , LKML Subject: Re: [PATCH] slab, slub: remove size disparity on debug kernel Message-ID: <20180314084329.y7735ecw2is5i5pd@esperanza> References: <20180313165428.58699-1-shakeelb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: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.