Received-SPF: pass (google.com: domain of linux-kernel+bounces-99949-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20190205155944.16007-1-dave.rodgman@arm.com> <ZeqFNf6Ay6yNq2kW@localhost.localdomain>
 <AS8PR08MB102898FB26D627E790FE8D4638F272@AS8PR08MB10289.eurprd08.prod.outlook.com>
In-Reply-To: <AS8PR08MB102898FB26D627E790FE8D4638F272@AS8PR08MB10289.eurprd08.prod.outlook.com>
From: Tao Liu <ltao@redhat.com>
Date: Tue, 12 Mar 2024 16:28:15 +0800
Message-ID: <CAO7dBbUvGRzwJKdcds2sr6T_KXnyubyOHtJe6kGG77eEcT1q0g@mail.gmail.com>
Subject: Re: [PATCH v5 0/3]: lib/lzo: run-length encoding support
To: Dave Rodgman <dave.rodgman@arm.com>, "markus@oberhumer.com" <markus@oberhumer.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Matt Sealey <Matt.Sealey@arm.com>, 
	"davem@davemloft.net" <davem@davemloft.net>, 
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, 
	"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>, "minchan@kernel.org" <minchan@kernel.org>, 
	"nitingupta910@gmail.com" <nitingupta910@gmail.com>, "rpurdie@openedhand.com" <rpurdie@openedhand.com>, 
	"sergey.senozhatsky.work@gmail.com" <sergey.senozhatsky.work@gmail.com>, 
	"sonnyrao@google.com" <sonnyrao@google.com>, 
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>, "sfr@canb.auug.org.au" <sfr@canb.auug.org.au>, nd <nd@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 8, 2024 at 8:32=E2=80=AFPM Dave Rodgman <dave.rodgman@arm.com> =
wrote:
>
> Hi Tao,
>
>
> I don=E2=80=99t see any reason for the upstream LZO library not to pick u=
p the lzo-rle algorithm from the kernel, and I would expect the same perfor=
mance benefit in userspace. This is really a question for Markus (the owner=
/maintainer of that library).
>
Hi Markus,

Is it possible to port the lzo-rle algorithm to the lzo library, so
userspace programs such as crash-utility or drgn can use it to
decompress the kernel data? Thanks in advance!

>
> I think the simplest short-term option would be to pull in the lzo librar=
y as source into crash-utility, and carry a patch against it to add support=
 for lzo-rle.

Hi Dave,

Thanks for the suggestion! I agree with your short-term option, this
is what we are planning to do for now. If lzo-rle has been integrated
into the lzo library, we can then delete the patch from crash-utility
code.

Thanks,
Tao Liu

>
>
> Dave
>
>
> From: Tao Liu <ltao@redhat.com>
> Date: Friday, 8 March 2024 at 03:26
> To: Dave Rodgman <dave.rodgman@arm.com>
> Cc: linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>, Matt Sea=
ley <Matt.Sealey@arm.com>, davem@davemloft.net <davem@davemloft.net>, gregk=
h@linuxfoundation.org <gregkh@linuxfoundation.org>, herbert@gondor.apana.or=
g.au <herbert@gondor.apana.org.au>, markus@oberhumer.com <markus@oberhumer.=
com>, minchan@kernel.org <minchan@kernel.org>, nitingupta910@gmail.com <nit=
ingupta910@gmail.com>, rpurdie@openedhand.com <rpurdie@openedhand.com>, ser=
gey.senozhatsky.work@gmail.com <sergey.senozhatsky.work@gmail.com>, sonnyra=
o@google.com <sonnyrao@google.com>, akpm@linux-foundation.org <akpm@linux-f=
oundation.org>, sfr@canb.auug.org.au <sfr@canb.auug.org.au>, nd <nd@arm.com=
>
> Subject: Re: [PATCH v5 0/3]: lib/lzo: run-length encoding support
>
> Hi Dave,
>
> On Tue, Feb 05, 2019 at 03:59:59PM +0000, Dave Rodgman wrote:
> > Hi,
> >
> > Following on from the previous lzo-rle patchset:
> >
> > https://lkml.org/lkml/2018/11/30/972
> >
> > This patchset contains only the RLE patches, and should be applied on t=
op of
> > the non-RLE patches ( https://lkml.org/lkml/2019/2/5/366 ).
> >
>
> Sorry for the interruption, since it is an old patchset and discussion.
> I have a few questions on lzo-rle support, hope you can give me some
> directions, thanks in advance!
>
> 1) Is lzo-rle suitable for userspace library? I've checked the current
> userspace lzo library lzo-2.10, it seems no lzo-rle support (Please
> correct me if I'm wrong). If lzo-rle have better performance in kernel,
> then is it possible to implement one in userspace and gain better
> performance as well?
>
> 2) Currently Yulong TANG have encountered problem that, crash utility
> cannot decompress a lzo-rle compressed zram since kernel 5.1 [1], since
> there is no lzo-rle support for current lzo library, crash have to
> import the kernel source code directly into crash, which is not good for
> crash utility code maintainance. It will be better if we can update lzo
> library with lzo-rle support. I guess not only crash, but also other
> kernel debugging tools running in userspace such as drgn may also need
> this feature.
>
> Do you have any suggestions on for these?
>
> [1]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00=
475.html
>
>
> Thanks,
> Tao Liu
>
>
> >
> > Previously, some questions were raised around the RLE patches. I've don=
e some
> > additional benchmarking to answer these questions. In short:
> >
> >  - RLE offers significant additional performance (data-dependent)
> >  - I didn't measure any regressions that were clearly outside the noise
> >
> >
> > One concern with this patchset was around performance - specifically, m=
easuring
> > RLE impact separately from Matt Sealey's patches (CTZ & fast copy). I h=
ave done
> > some additional benchmarking which I hope clarifies the benefits of eac=
h part
> > of the patchset.
> >
> > Firstly, I've captured some memory via /dev/fmem from a Chromebook with=
 many
> > tabs open which is starting to swap, and then split this into 4178 4k p=
ages.
> > I've excluded the all-zero pages (as zram does), and also the no-zero p=
ages
> > (which won't tell us anything about RLE performance). This should give =
a
> > realistic test dataset for zram. What I found was that the data is VERY
> > bimodal: 44% of pages in this dataset contain 5% or fewer zeros, and 44=
%
> > contain over 90% zeros (30% if you include the no-zero pages). This sup=
ports
> > the idea of special-casing zeros in zram.
> >
> > Next, I've benchmarked four variants of lzo on these pages (on 64-bit A=
rm at
> > max frequency): baseline LZO; baseline + Matt Sealey's patches (aka MS)=
;
> > baseline + RLE only; baseline + MS + RLE. Numbers are for weighted roun=
dtrip
> > throughput (the weighting reflects that zram does more compression than
> > decompression).
> >
> > https://drive.google.com/file/d/1VLtLjRVxgUNuWFOxaGPwJYhl_hMQXpHe/view?=
usp=3Dsharing
> >
> > Matt's patches help in all cases for Arm (and no effect on Intel), as e=
xpected.
> >
> > RLE also behaves as expected: with few zeros present, it makes no diffe=
rence;
> > above ~75%, it gives a good improvement (50 - 300 MB/s on top of the be=
nefit
> > from Matt's patches).
> >
> > Best performance is seen with both MS and RLE patches.
> >
> > Finally, I have benchmarked the same dataset on an x86-64 device. Here,=
 the
> > MS patches make no difference (as expected); RLE helps, similarly as on=
 Arm.
> > There were no definite regressions; allowing for observational error, 0=
1%
> > (3/4178) of cases had a regression > 1 standard deviation, of which the=
 largest
> > was 4.6% (1.2 standard deviations). I think this is probably within the=
 noise.
> >
> > https://drive.google.com/file/d/1xCUVwmiGD0heEMx5gcVEmLBI4eLaageV/view?=
usp=3Dsharing
> >
> > One point to note is that the graphs show RLE appears to help very slig=
htly
> > with no zeros present! This is because the extra code causes the clang
> > optimiser to change code layout in a way that happens to have a signifi=
cant
> > benefit. Taking baseline LZO and adding a do-nothing line like
> > "__builtin_prefetch(out_len);" immediately before the "goto next" has t=
he same
> > effect. So this is a real, but basically spurious effect - it's small e=
nough
> > not to upset the overall findings.
> >
> > Dave
> >
> >