[lustre-devel] Design proposal for client-side compression

[Anna Fuchs]

Jinshan,

On Wed, 2017-07-26 at 20:17 +0000, Xiong, Jinshan wrote:
> Thanks for the detailed explanation from Patrick.
>  
> “Does that mean, … Is there not any limit how many one
> client can have at one point of time?”
>  
> In theory, it’s possible that there exist that many active RPCs at
> one time, which is why I think it’s not feasible to have per-OSC page
> pool.

I see and agree, that could become a problem.

>  
> “… Once we have a smaller pool than
> we need, we have to block or skip compression, which is undesirable.
> But I don't know how to determine the required size.”
>  
> It’s probably not good to skip compression once it runs out of pages
> in pool, instead it should be blocked waiting for pages to be
> available. It will spend some time on waiting for the available
> pages, but at the end it will transfer less data over the network,
> and OST will also write less data to disk, so that it can still be
> performant.
> Of course, we can make it smarter by checking if there are too many
> threads waiting for available pages, and in that case we decide to
> not compress some RPCs. But this work can be deferred to the time
> after we have the code running and tune it by actual workload.

You are totally right, the smart tuning will be the second part of our
work, when the infrastructure is done. To start with something, we can
currently just block. 

> In order to decide the size of the pool, we should consider the
> number of CPUs on the client node, and the default RPC size. Let’s
> start with MAX(32, number_of_cpus) * default_RPC_size, and the
> default RPC size is 4MB in 2.10+ releases.

Thank you very much for the suggestions and explanations!

Anna