Merge lp:~deeptik/lava-test/tiobench into lp:lava-test/0.0

37 + "./tiobench.pl --block=4096 --block=8192 --threads=10 "\
38 + " --size=%s --numruns=2" % (VERSION, FILE_SIZE)]
Is there a reason why --block is specified twice?
Also, we need to scale this WAAAAAY back. Most of the devices we use are booted off a small SD card, so space is very limited. Also, 10 threads on a single-core, low power device is about 8 or 9 too many.

> 37 + "./tiobench.pl --block=4096 --block=8192 --threads=10 "\
> 38 + " --size=%s --numruns=2" % (VERSION, FILE_SIZE)]
> Is there a reason why --block is specified twice?
> Also, we need to scale this WAAAAAY back. Most of the devices we use are

I did not get with point "we need to scale this WAAAAAY back." Can you elaborate.?

> booted off a small SD card, so space is very limited. Also, 10 threads on a
> single-core, low power device is about 8 or 9 too many.

This is just an example of how the tiobench can be used. I basically written the tiobench to use the (disk) block size of 4096 and then 8192.
So in case if Linaro how much block size should be used ?

On Tue, 2010-10-05 at 17:44 +0000, Deepti B. Kalakeri wrote:
> > 37 + "./tiobench.pl --block=4096 --block=8192 --threads=10 "\
> > 38 + " --size=%s --numruns=2" % (VERSION, FILE_SIZE)]
> > Is there a reason why --block is specified twice?
> > Also, we need to scale this WAAAAAY back. Most of the devices we use are
>
> I did not get with point "we need to scale this WAAAAAY back." Can you elaborate.?
>
> > booted off a small SD card, so space is very limited. Also, 10 threads on a
> > single-core, low power device is about 8 or 9 too many.
>
> This is just an example of how the tiobench can be used. I basically written the tiobench to use the (disk) block size of 4096 and then 8192.
> So in case if Linaro how much block size should be used ?
ok, I see from reading the help that it seems you can specify --block
more than once with multiple runs and it will do both. I was thinking
maybe one of them was accidental. I don't have a problem with the block
size if you feel it is appropriate. As mentioned before, the two things
that seem to be causing problems here are the number of threads, and the
--size. As a point of reference, I have about 200M free on my sd card,
but there's no guarantee that every machine will. I don't know that
there's an easy way to tell it not to try to overconsume space, if not
then we just have to make a reasonable guess. I would not go over 2
threads.

I ran this on my beagle last night, and the test seemed to run fine but:
"test_results": [],
Likely something in the regexp, but I haven't had a chance to go through it yet. I'll try to take a look today if I get a chance.

Found the problem, you're regexp for the 2nd match line is too strict. Given that there's nothing else I see in the subsequent output that could get a false positive for it, I'd consider just having it match \d+\.\d+\.\d+\S+

2.6.35-1006-linaro-omap 512 4096 2 8.87 20.57% 1.747 1698.33 0.00000 0.00000 43

62 + test_id = ('%s_%s[kernel]_%s[filesize]_%s[blksize]') \
63 + % (test_case_id, kernel, filesize, blks_size)
I don't think I'd include the kernel in the test_case_id. The other parts of it are fine though I think.

64 + results['test_case_id'] = test_id
Let's match to a variable name other than test_case_id earlier on so that we don't have to do this.

Your test_case_id's currently come out looking something like this:
"SequentialReads_2.6.35-1006-linaro-omap[kernel]_512[filesize]_4096[blksize]"
This contains illegal characters, notably the []'s. The test_case_id pattern that it compares against for determining legality is:
"^([a-zA-Z0-9_-]+)(\.[a-zA-Z0-9_-]+)*$"

The merge has the following changes:

1) Removed the parsing of the kernel information
2) Changed the name of the group in pattern1 from test_case_id to test_id
3) Removed the [] in the final test_case_id
4) Associated the unit information as part of the final test_case_id to make it more meaningful

Approved, merging