On Friday, 3 August 2007 00:54, Alon Bar-Lev wrote: > On 8/3/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > First, please just replace LZF with LZO. If LZF is unsupported, there's no > > reason to drag it all the way. > > OK. > > > Second, you have added data copying in compress_compress(), which generally > > is not desirable. Can you avoid it? > > I will accept any other name... > I am not so good with English...
Well, I didn't meen the name of the function, which also could be different (like just "compress_page", for example), but the contents of it. Specifically, the memcpy() in there. > > [The long term idea is to use the compression algorithm as a "replacement" > > for > > memcpy().] > > You cannot do that... As it changes size... :) LZF does it as well, of course, and it's taken into account in the current code. > I don't understand exactly what you meant here... Please look at the code in prepare(), for example. In there, lzf_compress() is used to take page_size bytes of data from buf, compress them and place the result under the address block->data, with the assumption that the size of the result will be _less_ than page_size (otherwise, plain memcpy() is used). I think you should be able to do something like this with lzo1x_1_compress(). BTW, how exactly does lzo1x_1_compress() work? Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
