From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5AA8C388F3 for ; Mon, 30 Sep 2019 13:32:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B5624218AC for ; Mon, 30 Sep 2019 13:32:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="GTsAp7UQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731116AbfI3NcI (ORCPT ); Mon, 30 Sep 2019 09:32:08 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:52226 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728214AbfI3NcI (ORCPT ); Mon, 30 Sep 2019 09:32:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jwTg4fslkkXzfCclLjZOgIaOdnKQRQ6WQVeTB5C7GPs=; b=GTsAp7UQvIcIvL7TkWfOBSdUl M6EGMhlYfNT8cjQLHe/X55q53qvVOm4qHmblR+q079BsjQ5IJL6GR7NCHXZopzNuDhg6Olt9GWJZf TuWtjBJdrVKCPCz5dV157Ng6PX7X3d2OWKAE5dWwmbqm+fPiwDYPLZRIsGT9W7P5WF0RA/+YKwg1V ZOHTI5PeaKSpRxD64+n/Vso0SEIefZGFuhgMefh1Jc8e4GkOyMi2owWOVqPMkF1L4tFxZx/S6CMm1 CGRE7n3xBfoaoO/5xJs2pNSfHxGZzfESSdFdPlS3AMKKj3NdKP8XJoGmGlhxMVZVMbWyoc+BXXz04 KjNnO/TQQ==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.2 #3 (Red Hat Linux)) id 1iEvmW-0007wp-1A; Mon, 30 Sep 2019 13:32:04 +0000 Date: Mon, 30 Sep 2019 06:32:03 -0700 From: Matthew Wilcox To: Christopher Lameter Cc: Vlastimil Babka , Andrew Morton , David Sterba , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Pekka Enberg , David Rientjes , Ming Lei , Dave Chinner , "Darrick J . Wong" , Christoph Hellwig , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, James Bottomley , linux-btrfs@vger.kernel.org, Roman Gushchin , Johannes Weiner Subject: Re: [PATCH v2 2/2] mm, sl[aou]b: guarantee natural alignment for kmalloc(power-of-two) Message-ID: <20190930133203.GA26804@bombadil.infradead.org> References: <20190826111627.7505-1-vbabka@suse.cz> <20190826111627.7505-3-vbabka@suse.cz> <20190923171710.GN2751@twin.jikos.cz> <20190924165425.a79a2dafbaf37828a931df2b@linux-foundation.org> <6a28a096-0e65-c7ea-9ca9-f72d68948e10@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Sep 28, 2019 at 01:12:49AM +0000, Christopher Lameter wrote: > However, the layout may be different due to another allocator that prefers > to arrange things differently (SLOB puts multiple objects of different > types in the same page to save memory), if we need to add data to these > objects (debugging info, new metadata about the object, maybe the memcg > pointer, maybe other things that may come up), or other innovative > approaches (such as putting data of different kmem caches that are > commonly used together in the same page to improve locality). If we ever do start putting objects of different sizes that are commonly allocated together in the same page (eg inodes & dentries), then those aren't going to be random kmalloc() allocation; they're going to be special kmem caches that can specify "I don't care about alignment". Also, we haven't done that. We've had a slab allocator for twenty years, and nobody's tried to do that. Maybe the co-allocation would be a net loss (I suspect). Or the gain is too small for the added complexity. Whatever way, this is a strawman. > The cost is an unnecessary petrification of the data layout of the memory > allocators. Yes, it is. And it's a cost I'm willing to pay in order to get the guarantee of alignment.