Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: ieff94742:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-499-gf27bbf33e2-fm-20230619.001-gf27bbf33
Mime-Version: 1.0
Message-Id: <1be708d5-638c-40ff-bd52-b6b88c93d132@app.fastmail.com>
In-Reply-To: <E6B85BE5-10E8-4532-B599-1ACB83097A62@gmail.com>
References: <20230509165657.1735798-1-kent.overstreet@linux.dev>
 <20230509165657.1735798-8-kent.overstreet@linux.dev>
 <ZJAdhBIvwFBOFQU/@FVFF77S0Q05N>
 <20230619104717.3jvy77y3quou46u3@moria.home.lan>
 <ZJBOVsFraksigfRF@FVFF77S0Q05N.cambridge.arm.com>
 <20230619191740.2qmlza3inwycljih@moria.home.lan>
 <5ef2246b-9fe5-4206-acf0-0ce1f4469e6c@app.fastmail.com>
 <20230620180839.oodfav5cz234pph7@moria.home.lan>
 <dcf8648b-c367-47a5-a2b6-94fb07a68904@app.fastmail.com>
 <37d2378e-72de-e474-5e25-656b691384ba@intel.com>
 <ff2006db-cd13-48c4-bc5b-1864f9ec9149@app.fastmail.com>
 <bf22d1d1-ed6b-422d-9ea8-f778be841d8d@app.fastmail.com>
 <E6B85BE5-10E8-4532-B599-1ACB83097A62@gmail.com>
Date:   Tue, 20 Jun 2023 18:27:04 -0700
From:   "Andy Lutomirski" <luto@kernel.org>
To:     "Nadav Amit" <nadav.amit@gmail.com>
Cc:     "Dave Hansen" <dave.hansen@intel.com>,
        "Kent Overstreet" <kent.overstreet@linux.dev>,
        "Mark Rutland" <mark.rutland@arm.com>,
        "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
        linux-fsdevel@vger.kernel.org,
        "linux-bcachefs@vger.kernel.org" <linux-bcachefs@vger.kernel.org>,
        "Kent Overstreet" <kent.overstreet@gmail.com>,
        "Andrew Morton" <akpm@linux-foundation.org>,
        "Uladzislau Rezki" <urezki@gmail.com>,
        "hch@infradead.org" <hch@infradead.org>,
        linux-mm <linux-mm@kvack.org>,
        "Kees Cook" <keescook@chromium.org>,
        "the arch/x86 maintainers" <x86@kernel.org>
Subject: Re: [PATCH 07/32] mm: Bring back vmalloc_exec
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On Tue, Jun 20, 2023, at 3:43 PM, Nadav Amit wrote:
>> On Jun 20, 2023, at 3:32 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>=20
>>> // out needs to be zeroed first
>>> void unpack(struct uncompressed *out, const u64 *in, const struct=20
>>> bitblock *blocks, int nblocks)
>>> {
>>>    u64 *out_as_words =3D (u64*)out;
>>>    for (int i =3D 0; i < nblocks; i++) {
>>>        const struct bitblock *b;
>>>        out_as_words[b->target] |=3D (in[b->source] & b->mask) <<=20
>>> b->shift;
>>>    }
>>> }
>>>=20
>>> void apply_offsets(struct uncompressed *out, const struct uncompress=
ed *offsets)
>>> {
>>>    out->a +=3D offsets->a;
>>>    out->b +=3D offsets->b;
>>>    out->c +=3D offsets->c;
>>>    out->d +=3D offsets->d;
>>>    out->e +=3D offsets->e;
>>>    out->f +=3D offsets->f;
>>> }
>>>=20
>>> Which generates nice code: https://godbolt.org/z/3fEq37hf5
>>=20
>> Thinking about this a bit more, I think the only real performance iss=
ue with my code is that it does 12 read-xor-write operations in memory, =
which all depend on each other in horrible ways.
>
> If you compare the generated code, just notice that you forgot to=20
> initialize b in unpack() in this version.
>
> I presume you wanted it to say "b =3D &blocks[i]=E2=80=9D.

Indeed.  I also didn't notice that -Wall wasn't set.  Oops.