linux-kernel - Re: [fuse-devel] fuse: max_background and congestion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 15 Nov 2016 09:38:18 -0800
From:   Maxim Patlasov <mpatlasov@...tuozzo.com>
To:     Nikolaus Rath <Nikolaus@...h.org>
CC:     linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Miklos Szeredi <mszeredi@...hat.com>,
        <fuse-devel@...ts.sourceforge.net>
Subject: Re: [fuse-devel] fuse: max_background and congestion_threshold
 settings

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