Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 30 Apr 2020 10:15:58 -0700
From:   Roman Gushchin <guro@fb.com>
To:     Christopher Lameter <cl@linux.com>
CC:     Andrew Morton <akpm@linux-foundation.org>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Michal Hocko <mhocko@kernel.org>, <linux-mm@kvack.org>,
        <kernel-team@fb.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 04/19] mm: slub: implement SLUB version of
 obj_to_index()
Message-ID: <20200430171558.GA339283@carbon.dhcp.thefacebook.com>
References: <20200422204708.2176080-1-guro@fb.com>
 <20200422204708.2176080-5-guro@fb.com>
 <alpine.DEB.2.21.2004222349280.20021@www.lameter.com>
 <20200423000530.GA63356@carbon.lan>
 <alpine.DEB.2.21.2004250208500.7624@www.lameter.com>
 <20200425024625.GA107755@carbon.lan>
 <alpine.DEB.2.21.2004271618340.27701@www.lameter.com>
 <20200427164638.GC114719@carbon.DHCP.thefacebook.com>
 <alpine.DEB.2.21.2004301625490.1693@www.lameter.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.21.2004301625490.1693@www.lameter.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from carbon.dhcp.thefacebook.com (2620:10d:c090:400::5:b543) by CO2PR05CA0100.namprd05.prod.outlook.com (2603:10b6:104:1::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.14 via Frontend Transport; Thu, 30 Apr 2020 17:16:01 +0000
X-Originating-IP: [2620:10d:c090:400::5:b543]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: ecfa1f39-a011-43c1-948f-08d7ed2a28b7
X-MS-TrafficTypeDiagnostic: BYAPR15MB2920:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <BYAPR15MB2920BFEAB0743C63CC0BE4ADBEAA0@BYAPR15MB2920.namprd15.prod.outlook.com>
X-FB-Source: Internal
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 0389EDA07F
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: vnZsqdiMQRMJTV41eM2uAR84L0I2ig9lv1qBQknLwmI/2j+jK1WkE/COt4GNXEp2YnuW31XGyD8fWRKY2TH1qzHflOqH8+yVbSP4gB0s1HwH1IRUUTySYo+Da4nDQBzJ8J6IIKj53P8hUzPmbvbJiC7Qs1J5emTMnXFIQnfrMGUGpK2HEWgvUOpvtg87OO/p5BLCWznUgXnSXPon2TmGGaJWDUwkyb8ksArOHexqU5xB8LeQROYPigURxAp3K0eElbOqtX6E8JZz6CtGYf1ivGg+baDLMmpBIryO3v7TwP/BOLxfYMPAzgUMcu7fq4HerPtYy4SeIq3Atn1+k64NosCZoySVrRDOOaD0+KxaMZIezNK4W2m5K+Jel7i18MpzKQkPX134zcU4kEKW6hEIyT6h9DZ69p5sNwPfHyueGVjkZbSPKgAkOgx6N2+VhiSC
X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR15MB4136.namprd15.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:(396003)(136003)(39860400002)(376002)(346002)(366004)(66946007)(9686003)(55016002)(8676002)(6916009)(478600001)(52116002)(2906002)(5660300002)(6666004)(7696005)(54906003)(33656002)(186003)(16526019)(1076003)(316002)(66556008)(66476007)(8936002)(6506007)(4326008)(86362001);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: nJr74yMbhqwLkNnPcw6VxFp5A7D0eQgr6qJQqXxP6x1NkK2Fm3LUO73zBkt4NUPAUQl3zrfU1CMcdB3umGVsi2wW/glkt7MtxZc6jh0taUI2YX6fsCTYma4j+wZRU3aiaOqupA9940N8tVOgXAc/aQOYj5+VmUcDKkLSSCZK/FLt/bE10hPWl47fqWsHdSOrVstXU4MxF20UKGmgeVEVf9zkQgN1JhI/2bYUGVsgYGchOzF8vQGQsVXR34ERO1hejg0HFcyo4T4e5jf67UgtERjUw3qzpMDHXK06ZV6weq6G/W36qsj1SiGAcHzijH2RVyEt1jZTqt7p4hYZ4SO+Y4C29lZdfWbwA4jtTFxMIO9ljfdn0VkrgpHNk2lNgFFbHLRbm5kNYVAoA61Tm7OnVnB6NIjBrEbzO+8lMclN0UZrIFcNE7SU9qhUq7zBosEYCjJV77XSqGLta9m5DvbQJzReffsoY1nEcK0u6G6NSF9e4o8LOG3k1UnLZbV5bfRSj4nucAxSWvFt8jDEejtN15teV6/6VbHmfag+PBmzoWTMFCTGAoIFKiujzniLt/iqRWO99aFTAgcf5ofTGUk692IBxm5j0GOPAq4kEzz15oT7SLirAz2g7Af9bCgO96M6Ymlu2Lbm3QmPRymjhefjA6sQRjSBqwMio6G+7MyiiW+vrpm8AQCj8ywm8Mdy9GF+mrlP42kdFJO1Gfro8xP+vhgwKx+CR3Ml3F6BOG8O25MziE+mAUBOHJ+UxucriV8B0myn6+OkFXQNOdAWzALzQAL1TtvpRr3AjEEq1GTUmvEVh9CSxGVXXeJtJd06yPRwED3PrVofYPNT+tdnvsLpYw==
X-MS-Exchange-CrossTenant-Network-Message-Id: ecfa1f39-a011-43c1-948f-08d7ed2a28b7
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Apr 2020 17:16:02.5792
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: h4Qf+P7vLia+rs2mA40+8T7i7H7JknyGz0TfMFA1QkRSjUdisKRUT1cltNa46iJm
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2920
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.676
 definitions=2020-04-30_11:2020-04-30,2020-04-30 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 lowpriorityscore=0
 malwarescore=0 spamscore=0 bulkscore=0 adultscore=0 clxscore=1015
 suspectscore=1 mlxscore=0 impostorscore=0 mlxlogscore=913 phishscore=0
 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004300136
X-FB-Internal: deliver
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Apr 30, 2020 at 04:29:50PM +0000, Christoph Lameter wrote:
> On Mon, 27 Apr 2020, Roman Gushchin wrote:
> 
> > > Why do you need this? Just slap a pointer to the cgroup as additional
> > > metadata onto the slab object. Is that not much simpler, safer and faster?
> > >
> >
> > So, the problem is that not all slab objects are accounted, and sometimes
> > we don't know if advance if they are accounted or not (with the current semantics
> > of __GFP_ACCOUNT and SLAB_ACCOUNT flags). So we either have to increase
> > the size of ALL slab objects, either create a pair of slab caches for each size.
> 
> >
> > The first option is not that cheap in terms of the memory overhead. Especially
> > for those who disable cgroups using a boot-time option.
> 
> 
> If the cgroups are disabled on boot time then you can switch back to the
> compact version. Otherwise just add a pointer to each object. It will make
> it consistent and there is not much memory wastage.
> 
> The problem comes about with the power of 2 caches in the kmalloc array.

It's a very good point, and it's an argument to stick with the current design
(an external vector of memcg pointers).

> If one keeps the "natural alignment" instead of going for the normal
> alignment of slab caches then the alignment will cause a lot of memory
> wastage and thus the scheme of off slab metadata is likely going to be
> unavoidable.
> 
> But I think we are just stacking one bad idea onto another here making
> things much more complex than they could be. Well at least this justifies
> all our jobs .... (not mine I am out of work... hehehe)

Sorry, but what exactly do you mean?
I don't think reducing the kernel memory footprint by almost half
is such a bad idea.

Thanks!