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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
