Received-SPF: pass (google.com: domain of linux-nfs+bounces-3494-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <faf945a9-d1bc-45db-9543-057b7bc0ed8d@grimberg.me>
Date: Thu, 30 May 2024 21:19:55 +0300
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: NFS write congestion size
To: NeilBrown <neilb@suse.de>
Cc: Jan Kara <jack@suse.cz>, Trond Myklebust <trondmy@hammerspace.com>,
 "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
 "anna@kernel.org" <anna@kernel.org>
References: <> <a86fdd86-7c3a-44e9-9d49-4b3edfab66e6@grimberg.me>
 <171706807360.14261.8929224868643154972@noble.neil.brown.name>
Content-Language: en-US
From: Sagi Grimberg <sagi@grimberg.me>
In-Reply-To: <171706807360.14261.8929224868643154972@noble.neil.brown.name>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

>> btw, I think you meant that *slower* devices may need a larger queue to
>> saturate,
>> because if the device is fast, 256MB inflight is probably enough... So
>> you are solving
>> for the "consumer grade contemporary disks".
> No, faster devices.  The context here is random writes.  The more of
> those that are in the queue on the server, the more chance it has to
> re-order or coalesce requests.

Umm, what would reorder help with if writes are random?

> We don't want the device to go idle so we want lots of data buffered.
> It will take the client some moments to respond to the client-side queue
> dropping below a threshold by finding some pages to write and to submit
> them.  We don't want those moments to be long enough for the server-side
> queue to empty.

Yes I agree. I was just arguing that the faster the device is, the lower 
the completion
latency is. Meaning, if a device has a write-latency of 1us, you need a 
shorter queue than
a device that has a write-latency of 100ms.

Anyways, we're getting side-tracked...