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;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Subject: Re: [PATCH 07/32] mm: Bring back vmalloc_exec
From:   Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <bf22d1d1-ed6b-422d-9ea8-f778be841d8d@app.fastmail.com>
Date:   Tue, 20 Jun 2023 15:43:02 -0700
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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To:     Andy Lutomirski <luto@kernel.org>
Precedence: bulk


> 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 =
uncompressed *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 =
issue 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 =
initialize b in unpack() in this version.

I presume you wanted it to say "b =3D &blocks[i]=E2=80=9D.