From owner-svn-src-all@freebsd.org Thu Jun 7 03:00:00 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98388FF1096; Thu, 7 Jun 2018 03:00:00 +0000 (UTC) (envelope-from jonlooney@gmail.com) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 212B07936C; Thu, 7 Jun 2018 02:58:28 +0000 (UTC) (envelope-from jonlooney@gmail.com) Received: by mail-wm0-f50.google.com with SMTP id r125-v6so15567405wmg.2; Wed, 06 Jun 2018 19:58:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AFHrg6D4w2yjk+3sJKDCXujRedTDBCBQ7ZqzdhSWe4Q=; b=FlS8XH1NKpILYU8N3j0noZEJar67w0onHKPD+9VUdaKAfJjdFVQgzgcbm49VsOZqtF FJqQibbhCh529JAUwtfwv0yTVTT9VqW79a0PGXoOShg7cZfZHrms57m5doPg7UXrH0FF p2Ih5PKqre3e0N/jXjlPKiOqnhmpthYYvoh//umJdHR9GHLzCMwbA+3mRExFbEFlVKEN v3rqydJZyeb6pUENuUZF3Qhlqwl1AKcnsQP6yjpeN7FaD0kfbFDW1GguXvjt+gzVCqvD Im2qsZn1kSZd+N3Mb8lbojOXAqizZYd16tF6G1/tJ2xRnW26QLJMEhj24K8Uum97WVOJ I3kA== X-Gm-Message-State: APt69E0/3Dl+0nBnRJBZaXbDovsZyhaR0CHYnb7XizgCAPEy3MhRyayj vr9rQVnTKnQcyz5Webg7K/s0zkM/XgY= X-Google-Smtp-Source: ADUXVKLNQMLT9NiDZQAj2hZIXKm9An9WQDDBpEbTOCgftfI0r2F5c0cYPoWwymjaMyNTA/TXbrq8RQ== X-Received: by 2002:aa7:d419:: with SMTP id z25-v6mr460209edq.203.1528340306897; Wed, 06 Jun 2018 19:58:26 -0700 (PDT) Received: from mail-wr0-f176.google.com (mail-wr0-f176.google.com. [209.85.128.176]) by smtp.gmail.com with ESMTPSA id h2-v6sm3907865edq.6.2018.06.06.19.58.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jun 2018 19:58:26 -0700 (PDT) Received: by mail-wr0-f176.google.com with SMTP id f16-v6so8327446wrm.3; Wed, 06 Jun 2018 19:58:26 -0700 (PDT) X-Received: by 2002:adf:fb43:: with SMTP id c3-v6mr59330wrs.32.1528340306578; Wed, 06 Jun 2018 19:58:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:98e2:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 19:58:26 -0700 (PDT) In-Reply-To: <47E06039-234C-4078-A732-BFF230D2472B@panasas.com> References: <201806060508.w56586c9053686@repo.freebsd.org> <6E6E92B2-7536-4281-8EAF-72823E84902E@panasas.com> <47E06039-234C-4078-A732-BFF230D2472B@panasas.com> From: "Jonathan T. Looney" Date: Wed, 6 Jun 2018 22:58:26 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r334702 - head/sys/sys To: Ravi Pokala Cc: Mateusz Guzik , Mateusz Guzik , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 03:00:00 -0000 On Wed, Jun 6, 2018 at 10:14 PM, Ravi Pokala wrote: > > -----Original Message----- > From: on behalf of Mateusz Guzik < mjguzik@gmail.com> > Date: 2018-06-06, Wednesday at 09:01 > To: Ravi Pokala > Cc: Mateusz Guzik , src-committers < src-committers@freebsd.org>, , < svn-src-head@freebsd.org> > Subject: Re: svn commit: r334702 - head/sys/sys > > > On Wed, Jun 6, 2018 at 1:35 PM, Ravi Pokala wrote: > > > >>> + * Passing the flag down requires malloc to blindly zero the entire object. > >>> + * In practice a lot of the zeroing can be avoided if most of the object > >>> + * gets explicitly initialized after the allocation. Letting the compiler > >>> + * zero in place gives it the opportunity to take advantage of this state. > >> > >> This part, I still don't understand. :-( > > > > The call to bzero() is still for the full length passed in, so how does this help? > > > > bzero is: > > #define bzero(buf, len) __builtin_memset((buf), 0, (len)) > > I'm afraid that doesn't answer my question; you're passing the full length to __builtin_memset() too. I believe the theory is that the compiler (remember, this is __builtin_memset) can optimize away portions of the zeroing, or can optimize zeroing for small sizes. For example, imagine you do this: struct foo { uint32_t a; uint32_t b; }; struct foo * alloc_foo(void) { struct foo *rv; rv = malloc(sizeof(*rv), M_TMP, M_WAITOK|M_ZERO); rv->a = 1; rv->b = 2; return (rv); } In theory, the compiler can be smart enough to know that the entire structure is initialized, so it is not necessary to zero it. (I personally have not tested how well this works in practice. However, this change theoretically lets the compiler be smarter and optimize away unneeded work.) At minimum, it should let the compiler replace calls to memset() (and the loops there) with optimal instructions to zero the exact amount of memory that needs to be initialized. (Again, I haven't personally tested how smart the compilers we use are about producing optimal code in this situation.) Jonathan