[dm-devel] [PATCH] dm-writeboost: Remove unsure BUG() from init_rambuf_pool

Satoru Takeuchi satoru.takeuchi at gmail.com
Mon Jul 21 13:52:47 UTC 2014

Hi Alasdaia,

2014-07-20 3:13 GMT+09:00 Alasdair G Kergon <agk at redhat.com>:
> On Sat, Jul 19, 2014 at 08:40:52PM +0900, Satoru Takeuchi wrote:
>> In addition, I'd like to know your opinion about whether setting
>> the upper limit of nr_rambuf_pool argument is neccesary or not.
> 1) If it's a parameter passed from userspace under the control of the
> sysadmin, then you should just trust the sysadmin to set a sensible
> value, and only return an error if the value they ask for is unobtainable.

Thank you for your comment.

I don't say anything if this function returns an ENOMEM without any effect to
whole system. In this case, it fails *after* evicting massive amount of memory.
Since linux is used by very large amount of system, I consider someone will
eventually make a mistake. So I consider setting upper limit is better way
from the perspective of fool proof.

> Example: dm-ioctl.c copy_params()
> 2) If certain large values would be useless, leaving no memory for
> anything else, then you could apply a sensible limit based on the amount
> of memory available.

I agree with you.

It's difficult to guess the appropriate upper limit from the perspective of
dm-writeboost at this point since it's depend on system and requires
a number of performance measurements. So, the second best way is limiting
the rambuf size based on the available memory as you say. It can avoid
the above-mentioned problem anyway and very easy to implement.


> Example: dm_bufio.c
>  * Memory management policy:
>  *      Limit the number of buffers to DM_BUFIO_MEMORY_PERCENT of main memory
>  *      or DM_BUFIO_VMALLOC_PERCENT of vmalloc memory (whichever is lower).
>  *      Always allocate at least DM_BUFIO_MIN_BUFFERS buffers.
> Alasdair

More information about the dm-devel mailing list