oh - and think of linux software suspend.
take a notebook with 2 GB of ram - that takes a while to write that to disk and read that back again.
using lzo compression for this may probably halve the time for suspend/resume
using a fast compression scheme
> -----Ursprüngliche Nachricht-----
> Von: [email protected]
> Gesendet: 11.05.07 22:48:15
> An: [email protected]
> CC: [email protected],[email protected]
> Betreff: Re: [PATCH] Add LZO1X compression support to the kernel
>
> >Why is this needed? What code plans to use it?
>
> it`s pretty useful because it`s and a damn fast and damn cpu friendly compression alorithm.
>
> afaik, there is already a least one linux kernel-feature (under development) which is using lzo compression:
> see compressed caching project at http://linux-mm.org/CompressedCaching & http://linuxcompressed.sourceforge.net/
>
> seems, they have also done porting it to the kernel, so there is probably choice between two implemetations to merge.
>
> >How many buffer overruns are there in it?
>
> i don`t know :)
> but, from a user-perspective, lzo is really portable and seems to be a rock solid compression scheme.
> i`m sucessfully using it for years (lzop utility) and i know projects which compress gigabytes of data every day with lzop.
> furthermore, i know of at least 40 software projects using lzo compression, so this should have some level of maturity.
>
> maybe i can add another software integrating lzo compression to the enumeration at http://www.lzop.de ? ;)
>
> regards
> roland
>
>
> List: linux-kernel
> Subject: Re: [PATCH] Add LZO1X compression support to the kernel
> From: Andrew Morton <akpm () linux-foundation ! org>
> Date: 2007-05-10 6:21:29
> Message-ID: 20070509232129.371f49d5.akpm () linux-foundation ! org
> [Download message RAW]
>
> On Wed, 02 May 2007 09:56:23 +0100 Richard Purdie <[email protected]> wrote:
>
> > Current thinking is that lzo should get merged directly followed by the
> > subsystem parts through their specific trees. It appears this should
> > make it onto LKML despite the size so here goes.
> >
> > Please keep in mind I haven't reformatted the LZO code itself as if I do
> > so, it will make maintenance of it against any changes in LZO itself
> > near impossible. In its current form, it should be possible to diff
> > against upstream. All the bad formatting is confined to a handful of
> > files in lib/lzo/ and the kernel interface should be clean.
> >
> > I realise a maze of ifdefs still remain. I've already spent a lot of
> > time removing a ton of them and going much further might start to affect
> > diffability of the code - I hoping whats there is a good compromise.
> >
> > I've asked the LZO author about the comments on lzo_copyright function
> > but the code is GPLv2 licensed so is suitable for inclusion in the
> > kernel.
> >
> >
> >
> > Add LZO1X compression/decompression support to the kernel.
> >
> > This is based on the standard userspace lzo library, particularly
> > minilzo with the headers much trimmed down and simplified for kernel
> > use. Its structured so that it should still diff with the userspace
> > version for ease of future updating.
>
> Well that's attractive-looking code.
>
> Why is this needed? What code plans to use it?
>
> How many buffer overruns are there in it?
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
