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

Maxim Patlasov
2016-11-16T13:09:12Z

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