Messages in this thread | | | Subject | Re: [fuse-devel] fuse: max_background and congestion_threshold settings | From | Maxim Patlasov <> | Date | Tue, 15 Nov 2016 09:38:18 -0800 |
| |
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
| |