Re: Reiser4 und LZO compression

[Hans Reiser <reiser@namesys.com>]

Edward Shishkin wrote:
> Clemens Eisserer wrote:
>>> But speaking of single threadedness, more and more desktops are
>>> shipping
>>> with ridiculously more power than people need.  Even a gamer really
>>
>> Will the LZO compression code in reiser4 be able to use
>> multi-processor systems?
>> E.g. if I've a Turion-X2 in my laptop will it use 2 threads for
>> compression/decompression making cpu throughput much better than
>> whatthe disk could do?
>>
>
> Compression is going in flush time and there can be more then
> one flush thread that processes the same transaction atom.
> Decompression is going in the context of readpage/readpages.
> So if you mean per file, then yes for compression and no for
> decompression.
I don't think your explanation above is a good one.

If there is more than one process reading a file, then you can have
multiple decompressions at one time of the same file, yes?

Just because there can be more than one flush thread per file does not
mean it is likely there will be.

CPU scheduling of compression/decompression is an area that could use
work in the future.    For now, just understand that what we do is
better than doing nothing.;-/
>
> Edward.
>
>
>> lg Clemens
>>
>>
>> 2006/8/30, Hans Reiser <reiser@namesys.com>:
>>
>>> Edward Shishkin wrote:
>>> >
>>> > (Plain) file is considered as a set of logical clusters (64K by
>>> > default). Minimal unit occupied in memory by (plain) file is one
>>> > page. Compressed logical cluster is stored on disk in so-called
>>> > "disk clusters". Disk cluster is a set of special items (aka
>>> "ctails",
>>> > or "compressed bodies"), so that one block can contain (compressed)
>>> > data of many files and everything is packed tightly on disk.
>>> >
>>> >
>>> >
>>> So the compression unit is 64k for purposes of your benchmarks.
>>>
>>
>>
>
>
>