Re: [RFC] LZO de/compression support - take 6

[Daniel Hazelton <dhazelton@enter.net>]

On Monday 28 May 2007 13:11:15 Adrian Bunk wrote:
> On Mon, May 28, 2007 at 09:33:32PM +0530, Nitin Gupta wrote:
> > On 5/28/07, Adrian Bunk <bunk@stusta.de> wrote:
> >...
> >
> >> - then ensure that it works correctly on all architectures and
> >
> > Already tested on x86, amd64, ppc (by Bret). I do not have machines
> > from other archs available. Bret tested 'take 3' version but no
> > changes were introduced in further revisions that could affect
> > correctness - but still it will be good to have this version tested
> > too. Only with inclusion in -mm and testing by much wider user base
> > can make it to mainline (I suppose nobody uses -mm for production use
> > anyway).
> >
> >>   document why your version is that much faster than the original
> >>   version and why you know your optimizations have no side effects
> >
> > Replied in earlier mail regarding this.
> >...
>
> I have not seen any explanations:
> - Why did the upstream author write the code that way?
> - Why are your changes correct?
> - Why do your changes allow the compiler to produce faster code?

Would it help if I added instrumentation code to both the upstream code and 
the stripped down code in question?

> The upstream author of the code is available - and he might be able to
> help you getting answers. No matter whether your changes are incorrect
> or correct optimizations that should go upstream, in both cases
> discussing these issues with upstream is the best solution.
>
> And testing is nice, but if you broke some case that's outside of your
> tests you'll never notice.

Any suggestions for tests I could add to the boilerplate I've been using to 
benchmark the code? I'll add a few tests that use random input rather than 
one of the source files - I'd add a test to see how it deals with NULL input, 
but I ran into that in an early version of the testbed (where I had a typo 
that stopped the code from working) and the compressor didn't like it. And I 
suppose I could put in a test that reads in a chunk of /dev/mem or have it 
get a chunk of data from HAL/DBus as well.

But if anyone has a suggestion of what tests I could toss at it to really 
stress the code, let me know and I'll get to work extending this code so it 
can stress test both the standard implementation of miniLZO *and* this 
stripped down 'Tiny' version.

DRH

> > - Nitin
>
> cu
> Adrian


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/