Keir, Jan -- In theory, would there be any objections to updating Xen''s lzo.c and unlzo.c to accomodate Markus Oberhumer''s dramatic performance improvements recently posted to upstream Linux targeted for 3.8 and briefly described here: https://lkml.org/lkml/2012/8/21/350 (short version: typically 2x faster) Also, might it be reasonable/acceptable for this to retain the Linux formatting so that this and future updates need not be reformatted? AFAIK, tmem is the only user of this code. Thanks, Dan
>>> On 27.11.12 at 01:33, Dan Magenheimer <dan.magenheimer@oracle.com> wrote: > In theory, would there be any objections to updating > Xen''s lzo.c and unlzo.c to accomodate Markus Oberhumer''s > dramatic performance improvements recently posted to > upstream Linux targeted for 3.8 and briefly described here: > > https://lkml.org/lkml/2012/8/21/350 > (short version: typically 2x faster)No objection from me.> Also, might it be reasonable/acceptable for > this to retain the Linux formatting so that > this and future updates need not be reformatted?You contributed that file originally with not-really-Linux, not-really-Xen formatting. The decompressors I added later based on Linux code all retained the Linux coding style, so getting the LZO code aligned back is certainly in line with that (and our general policy).> AFAIK, tmem is the only user of this code.Not anymore - the Dom0 kernel may come LZO-compressed, and hence the decompression code is also being used there. Jan
On 27/11/2012 08:25, "Jan Beulich" <JBeulich@suse.com> wrote:>>>> On 27.11.12 at 01:33, Dan Magenheimer <dan.magenheimer@oracle.com> wrote: >> In theory, would there be any objections to updating >> Xen''s lzo.c and unlzo.c to accomodate Markus Oberhumer''s >> dramatic performance improvements recently posted to >> upstream Linux targeted for 3.8 and briefly described here: >> >> https://lkml.org/lkml/2012/8/21/350 >> (short version: typically 2x faster) > > No objection from me.Nor me, I agree with all Jan says. K.>> Also, might it be reasonable/acceptable for >> this to retain the Linux formatting so that >> this and future updates need not be reformatted? > > You contributed that file originally with not-really-Linux, > not-really-Xen formatting. The decompressors I added later > based on Linux code all retained the Linux coding style, so getting > the LZO code aligned back is certainly in line with that (and our > general policy). > >> AFAIK, tmem is the only user of this code. > > Not anymore - the Dom0 kernel may come LZO-compressed, and > hence the decompression code is also being used there. > > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel