[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXGA=kBdahDTuFDPzZKf5bbvxH2Ns7Ows+5D-PAx8rwP2w@mail.gmail.com>
Date: Mon, 17 Oct 2022 23:16:35 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: "Guilherme G. Piccoli" <gpiccoli@...lia.com>
Cc: Kees Cook <keescook@...omium.org>,
Anton Vorontsov <anton@...msg.org>,
Colin Cross <ccross@...roid.com>,
Tony Luck <tony.luck@...el.com>, linux-kernel@...r.kernel.org,
linux-hardening@...r.kernel.org
Subject: Re: [PATCH] pstore: migrate to crypto acomp interface (take 2)
On Mon, 17 Oct 2022 at 23:10, Guilherme G. Piccoli <gpiccoli@...lia.com> wrote:
>
> On 17/10/2022 18:01, Ard Biesheuvel wrote:
> > [...]
> >
> > In summary, we're better off sticking with the legacy comp interface,
> > but unfortunately, due to the way that has been plumbed into the
> > scomp/acomp with scatterlists version, that doesn't really help us get
> > rid of the memory overhead.
> >
>
> Out of curiosity, do you have a number here, like X kilobytes per active
> CPU?
2x128 KB per CPU, which makes 128 KB also the maximum input/output
size per request when using this interface. (SCOMP_SCRATCH_SIZE)
On my 32x4 CPU workstation, this amounts to 32 MB permanently locked
up for nothing when the pstore driver is loaded (with compression
enabled)
Powered by blists - more mailing lists