Date: Thu, 07 Jun 2018 00:01:00 -0400 From: Ravi Pokala <rpokala@freebsd.org> To: "Jonathan T. Looney" <jtl@freebsd.org> Cc: Mateusz Guzik <mjguzik@gmail.com>, Mateusz Guzik <mjg@freebsd.org>, src-committers <src-committers@freebsd.org>, <svn-src-all@freebsd.org>, <svn-src-head@freebsd.org> Subject: Re: svn commit: r334702 - head/sys/sys Message-ID: <468B8AB5-D2C7-4033-9F24-6E1F94DC7137@panasas.com> In-Reply-To: <CADrOrmu5gYakgXu4bM9CMh5zQa2LZv6pA7tTEScoZH-hs9hMTQ@mail.gmail.com> References: <201806060508.w56586c9053686@repo.freebsd.org> <6E6E92B2-7536-4281-8EAF-72823E84902E@panasas.com> <CAGudoHF9Kw6gFyNkJADzCCg0vvSq-o%2BrWwxBX15cKszDSV5KiA@mail.gmail.com> <47E06039-234C-4078-A732-BFF230D2472B@panasas.com> <CADrOrmu5gYakgXu4bM9CMh5zQa2LZv6pA7tTEScoZH-hs9hMTQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I believe the theory is that the compiler (remember, this is __builtin_me=
mset) can optimize away portions of the zeroing, or can optimize zeroing for=
small sizes.
Ahhh! I didn't consider that the compiler would be doing analysis of the la=
rger context, and potentially skipping zeroing parts that are set immediatel=
y after the call.
Thanks!
-Ravi (rpokala@)
=EF=BB=BF-----Original Message-----
From: "Jonathan T. Looney" <jtl@freebsd.org>
Date: 2018-06-06, Wednesday at 22:58
To: Ravi Pokala <rpokala@freebsd.org>
Cc: Mateusz Guzik <mjguzik@gmail.com>, Mateusz Guzik <mjg@freebsd.org>, src=
-committers <src-committers@freebsd.org>, <svn-src-all@freebsd.org>, <svn-sr=
c-head@freebsd.org>
Subject: Re: svn commit: r334702 - head/sys/sys
> On Wed, Jun 6, 2018 at 10:14 PM, Ravi Pokala <rpokala@freebsd.org> wrote:
>>
>> -----Original Message-----
>> From: <owner-src-committers@freebsd.org> on behalf of Mateusz Guzik <mjg=
uzik@gmail.com>
>> Date: 2018-06-06, Wednesday at 09:01
>> To: Ravi Pokala <rpokala@freebsd.org>
>> Cc: Mateusz Guzik <mjg@freebsd.org>, src-committers <src-committers@free=
bsd.org>, <svn-src-all@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 <rpokala@freebsd.org> 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 ob=
ject
>>>>> + * gets explicitly initialized after the allocation. Letting the com=
piler
>>>>> + * 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))
>>=20
>> I'm afraid that doesn't answer my question; you're passing the full leng=
th to __builtin_memset() too.
>=20
> I believe the theory is that the compiler (remember, this is __builtin_me=
mset) can optimize away portions of the zeroing, or can optimize zeroing for=
small sizes.
>=20
> For example, imagine you do this:
>=20
> struct foo {
> uint32_t a;
> uint32_t b;
> };
>=20
> struct foo *
> alloc_foo(void)
> {
> struct foo *rv;
>=20
> rv =3D malloc(sizeof(*rv), M_TMP, M_WAITOK|M_ZERO);
> rv->a =3D 1;
> rv->b =3D 2;
> return (rv);
> }
>=20
> In theory, the compiler can be smart enough to know that the entire struc=
ture is initialized, so it is not necessary to zero it.
>=20
> (I personally have not tested how well this works in practice. However, t=
his change theoretically lets the compiler be smarter and optimize away unne=
eded work.)
>=20
> 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 t=
hat needs to be initialized. (Again, I haven't personally tested how smart t=
he compilers we use are about producing optimal code in this situation.)
>=20
> Jonathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?468B8AB5-D2C7-4033-9F24-6E1F94DC7137>