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.4 required=3.0 tests=DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,T_DKIM_INVALID, USER_AGENT_MUTT autolearn=ham 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 94C2FC28CF6 for ; Wed, 1 Aug 2018 15:51:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3901C208A3 for ; Wed, 1 Aug 2018 15:51:55 +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="O/FY0+ar" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3901C208A3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389917AbeHARiN (ORCPT ); Wed, 1 Aug 2018 13:38:13 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:56254 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389557AbeHARiM (ORCPT ); Wed, 1 Aug 2018 13:38:12 -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=JGGGUPL8y+Sg9MFwW8cY9lJ3vvwCFtGeyT8ocGR/Lto=; b=O/FY0+arLoN3yvgTDaQdaP11A sFtp5jmbphrcnIRsmYkDI6jzby+x3hdhhGH3Ej6fnPHKWn7LDNSAILFeGxDnyf4U/5c9pbbsXbsdx nDfAIa7IkUvZkijysDA0qV/s1PLw0ypgiXnmO1KDQpyR6c+Nm5OuyiTjH/meSWVYUkR+XBCouLEaj EyWd3E80RP3YZd75oTyxmuRBQqCWjdwPRKt5lDbOd6qWUOS4lqmkSfAO9kV/ndWWGjUZM/kvOKUW4 AJxw6be/Xd8UB4g7HoVlVPBHIUpOqakiXSHWwvAcTONZp83sKS2ay+yxDO6bPxhI42ERKRVlbTp3/ DZcU9JLhg==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1fktPU-0004Ho-UI; Wed, 01 Aug 2018 15:51:36 +0000 Date: Wed, 1 Aug 2018 08:51:36 -0700 From: Matthew Wilcox To: Eric Dumazet Cc: Christoph Lameter , Dmitry Vyukov , Eric Dumazet , Andrey Ryabinin , Linus Torvalds , Theodore Ts'o , jack@suse.com, linux-ext4@vger.kernel.org, Greg Kroah-Hartman , Pablo Neira Ayuso , Jozsef Kadlecsik , Florian Westphal , David Miller , netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev , Gerrit Renker , dccp@vger.kernel.org, jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com, airlied@linux.ie, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Alexey Kuznetsov , Hideaki YOSHIFUJI , Ursula Braun , linux-s390@vger.kernel.org, LKML , Andrew Morton , linux-mm , Andrey Konovalov , linux-fsdevel@vger.kernel.org Subject: Misuse of constructors Message-ID: <20180801155136.GB4039@bombadil.infradead.org> References: <01000164f169bc6b-c73a8353-d7d9-47ec-a782-90aadcb86bfb-000000@email.amazonses.com> <30ee6c72-dc90-275a-8e23-54221f393cb0@virtuozzo.com> <01000164f60f3f12-b1253c6e-ee57-49fc-aed8-0944ab4fd7a2-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 01, 2018 at 08:37:07AM -0700, Eric Dumazet wrote: > The idea of having a ctor() would only be a win if all the fields that > can be initialized in the ctor are contiguous and fill an integral > number of cache lines. Let's state it more generally: Having a ctor is only a win if it allows the user to avoid reading or writing a significant number of cachelines. For example, the radix tree node occupies nine cachelines (576 bytes). The typical user will touch two of those cacheliens (the header and the cacheline which contains the slot of interest). That's seven cachelines which don't even need to be read, let alone written. I think filesystems are particularly prone to this antipattern of initialising some of their inode with a ctor and the remainder at alloc_inode() time (compare the locations of the struct members touched by inode_init_always() and inode_init_once()).