On Sat, Feb 22, 2025 at 7:34 PM Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Sat, Feb 22, 2025 at 07:26:43PM +1300, Barry Song wrote:
> >
> > After reviewing the zRAM code, I don't see why zram_write_page() needs
> > to rely on
> > comp_len to call write_incompressible_page().
> >
> > zram_write_page()
> > {
> > ret = zcomp_compress(zram->comps[ZRAM_PRIMARY_COMP], zstrm,
> > mem, &comp_len);
> > kunmap_local(mem);
> >
> > if (unlikely(ret)) {
> > zcomp_stream_put(zstrm);
> > pr_err("Compression failed! err=%d\n", ret);
> > return ret;
> > }
> >
> > if (comp_len >= huge_class_size) {
> > zcomp_stream_put(zstrm);
> > return write_incompressible_page(zram, page, index);
> > }
> > }
>
> Surely any compression error should just be treated as an
> incompressible page?
probably no, as an incompressible page might become compressible
after changing an algorithm. This is possible, users may swith an
algorithm to compress an incompressible page in the background.
Errors other than dst_buf overflow are a completely different matter
though :-)
>
> I mean we might wish to report unusual errors in case the
> admin or developer can do something about it, but for the
> system as a whole it should still continue as if the page
> was simply incompressible.
>
> > As long as crypto drivers consistently return -ENOSP or a specific error
> > code for dst_buf overflow, we should be able to eliminate the
> > 2*PAGE_SIZE buffer.
>
> Yes we could certainly do that.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
Thanks
barry
