Subject: Re: [fuse-devel] fuse: max_background and congestion_threshold
 settings
References: <87oa1g90nx.fsf@thinkpad.rath.org>
From: Maxim Patlasov <mpatlasov@virtuozzo.com>
CC: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Miklos Szeredi <mszeredi@redhat.com>,
        <fuse-devel@lists.sourceforge.net>
To: Nikolaus Rath <Nikolaus@rath.org>
Message-ID: <64a57faa-d3a6-a209-8728-723ed7f37c2f@virtuozzo.com>
Date: Tue, 15 Nov 2016 09:38:18 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <87oa1g90nx.fsf@thinkpad.rath.org>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2016 17:38:28.7666 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1851
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1904
Lines: 49

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