Re: [fuse-devel] fuse: max_background and congestion_threshold settings

[Maxim Patlasov <mpatlasov@virtuozzo.com>]

Hi,


On 11/15/2016 08:18 AM, Nikolaus Rath wrote:
> Hello,
>
> Could someone explain to me the meaning of the max_background and
> congestion_threshold settings of the fuse module?
>
> At first I assumed that max_background specifies the maximum number of
> pending requests (i.e., requests that have been send to userspace but
> for which no reply was received yet). But looking at fs/fuse/dev.c, it
> looks as if not every request is included in this number.

fuse uses max_background for cases where the total number of 
simultaneous requests of given type is not limited by some other natural 
means. AFAIU, these cases are: 1) async processing of direct IO; 2) 
read-ahead. As an example of "natural" limitation: when userspace 
process blocks on a sync direct IO read/write, the number of requests 
fuse consumed is limited by the number of such processes (actually their 
threads). In contrast, if userspace requests 1GB direct IO read/write, 
it would be unreasonable to issue 1GB/128K==8192 fuse requests 
simultaneously. That's where max_background steps in.

>
> I also figured out that if the number of background requests (whatever
> they are) exceeds the congestion threshold, fuse calls
> set_bdi_congested() for the backing device. But what does this do?

AFAIU, this is a hint for reclaimer to avoid busy loop:

>         /*
>          * If kswapd scans pages marked marked for immediate
>          * reclaim and under writeback (nr_immediate), it implies
>          * that pages are cycling through the LRU faster than
>          * they are written so also forcibly stall.
>          */
>         if (nr_immediate && current_may_throttle())
>             congestion_wait(BLK_RW_ASYNC, HZ/10);


> And
> does this become a no-op if there is no backing device?

current->backing_dev_info exists (and helps to control writeback) even 
if there is no "real" backing device.

Thanks,
Maxim