Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1004079imm; Wed, 1 Aug 2018 08:40:29 -0700 (PDT) X-Google-Smtp-Source: AAOMgpe8TziVBkjuLHd3du7OK1girWLvAOLuc1ocYEzLUuG6tiscydVFBylCV3pVgFlxFG8xX3Rw X-Received: by 2002:a63:5624:: with SMTP id k36-v6mr25136549pgb.146.1533138029624; Wed, 01 Aug 2018 08:40:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533138029; cv=none; d=google.com; s=arc-20160816; b=mYv9vWq1VuBnf3P2a7fahHk8jyXtJKuWiUG9XDF50p+lfOMX5vGaK8/b5QLp2NBP2G hHE/Z/2hLrzNRA1gEGI74NkIFEvCBCEt5BDcOIryru6t9KPnkhqEp633c4zMEfReRG0o 2JGCBWD2KOLXc5Aln9+eqbC03xJ7b3awOfrw77oKP9m56Tz5os2J09qCALJmzO38fUxp a+s+Sm28bsmGujm7VvA5b0e4MFXCBKB3AZbZL4wdEpppUAIqDkAl71k8ZFte8paT0kxS xhNdv6Eq6Vh70Q12BlG/FZnwO7TI6rGApsCKGHTixsgd65h0Oqz2qKYO8Kuws32txZDt XrmQ== 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 :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=MYJunNEVWlmzNNDtapRgMnjsKoYuiuXI8lWxs+kk20E=; b=FJ0XT3rxRP7XUtlWFpuZ+fT1yBhw6xevr4kLyK4vH7F4UFM7tuctVFojx00tkHERUM i+k9grGlqoJRzq4x8sEeVrVR1RfI119GPiYZsNbdZvNAqsKTjRCka/0TiOGmh0E41K+t zi/yGC/GAkLwpyDl6zBimGcEc/ag55lwwzi+CMtvBVuOL2+CerKQ4Dm0VXZq9l5hO47j rXCIcHGMvVVIx7jdmHFCH2Bm8I/ulc4A2YnyHnxJC4BBL+XsZ0r9M2TnyejZ6DcwM3xf 2UYTNM0LenTM/AbT+kVB4Sh9Tb/wQcGzxSdCWPnrmmZOcdBMwte8zUU3Px3YX0aSojpc w0VA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=jxPysqg3; 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 b8-v6si15198312pls.392.2018.08.01.08.39.51; Wed, 01 Aug 2018 08:40:29 -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=jxPysqg3; 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 S2389816AbeHARXg (ORCPT + 99 others); Wed, 1 Aug 2018 13:23:36 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:37402 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389729AbeHARXf (ORCPT ); Wed, 1 Aug 2018 13:23:35 -0400 Received: by mail-it0-f68.google.com with SMTP id h20-v6so9914083itf.2 for ; Wed, 01 Aug 2018 08:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MYJunNEVWlmzNNDtapRgMnjsKoYuiuXI8lWxs+kk20E=; b=jxPysqg36iwmptkMEqeHklYxd+Jsg58smCvOJlJhaM2Rxvcpbz33A8haYs5Ot0dnZ6 TphrQCMIeI7jI4o6vpcYRwjF887dvLclodjEEPvvjIvG4muc/x3Ov8uiEbcsV8lHpeam /HZJIlB2oM2fdyuqBFXu2PiaKy5T2/tUaGiPSHkPbvHS0UngtuhdWD3n+T80Eqqwy0Fd UInhEwdYqGZVOkxrezhXWd+g1W6sdhHVrRD2X5K/puKkkiLdM8wJMKbPN7qw1GuzMe3E GKs6mn1FnKu+uF8lCJPUEzUCtqgUYwsCCOtg8q2HiUMDSclTMFGqanzd+eZAbgeUkVfF dS/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MYJunNEVWlmzNNDtapRgMnjsKoYuiuXI8lWxs+kk20E=; b=MHlSS82c6eEAHubvIJ0a9xC6qeEavSfmD2IgqoJnnT4pHO2uCgDlSv3D/cDVjWA4Ro nxgIaN3VSc8pjoglRBsh9SlXyxSsfvaaFDeN7llhWp0sbatzcQ9ot2ZG5VM46LCqsy1D GnbAlcSqUoeMNHTUAfmCRkNHvPxANa+k7MJt40JKsGWUbzGUYAB2LLayfbgQT0gloSU/ YrPlhT6rXRkOkUC6bwRXNeyibgSQNSf6G7D6fW47O2g4mPyTQXSOWyFmdNZ0tWj6vh9r aC2tIjy9tGB3n3BfmKhwaRCLP7Gfx0G7cwEMf2nfNHJj4Z5/na7o6Zg4s7Az/3srz5sB Yb5w== X-Gm-Message-State: AOUpUlFuFKalaLGfygJ+WA7qbfi5dsmfTOnLDF0oyHFsroysuQtL9F/O lLF2rfztGr+z16iZjg7UZZaetcnUIA9cmJEBwU0a5w== X-Received: by 2002:a02:b687:: with SMTP id i7-v6mr24993805jam.55.1533137838525; Wed, 01 Aug 2018 08:37:18 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <01000164f60f3f12-b1253c6e-ee57-49fc-aed8-0944ab4fd7a2-000000@email.amazonses.com> From: Eric Dumazet Date: Wed, 1 Aug 2018 08:37:07 -0700 Message-ID: Subject: Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation) To: Christoph Lameter Cc: 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 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, Aug 1, 2018 at 8:15 AM Christopher Lameter wrote: > > On Wed, 1 Aug 2018, Dmitry Vyukov wrote: > > > But we are trading 1 indirect call for comparable overhead removed > > from much more common path. The path that does ctors is also calling > > into page alloc, which is much more expensive. > > So ctor should be a net win on performance front, no? > > ctor would make it esier to review the flow and guarantee that the object > always has certain fields set as required before any use by the subsystem. > > ctors are run once on allocation of the slab page for all objects in it. > > ctors are not called duiring allocation and freeing of objects from the > slab page. So we could avoid the intialization of the spinlock on each > object allocation which actually should be faster. This strategy might have been a win 30 years ago when cpu had no caches (or too small anyway) What probability is that the 60 bytes around the spinlock are not touched after the object is freshly allocated ? -> None Writing 60 bytes in one cache line instead of 64 has really the same cost. The cache line miss is the real killer. Feel free to write the patches, test them, but I doubt you will have any gain. Remember btw that TCP sockets can be either completely fresh (socket() call, using memset() to clear the whole object), or clones (accept() thus copying the parent socket) 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.