Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937378AbdLRR12 (ORCPT ); Mon, 18 Dec 2017 12:27:28 -0500 Received: from mout.gmx.net ([212.227.17.21]:62488 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935925AbdLRR1O (ORCPT ); Mon, 18 Dec 2017 12:27:14 -0500 Message-ID: <1513618019.7113.27.camel@gmx.de> Subject: Re: NFS: 82ms wakeup latency 4.14-rc4 From: Mike Galbraith To: Trond Myklebust , "bfields@fieldses.org" Cc: "linux-kernel@vger.kernel.org" , "linux-nfs@vger.kernel.org" , "jlayton@kernel.org" Date: Mon, 18 Dec 2017 18:26:59 +0100 In-Reply-To: <1513617866.4581.6.camel@primarydata.com> References: <1513610231.7998.13.camel@gmx.de> <1513611112.7113.1.camel@gmx.de> <20171218163559.GA11829@fieldses.org> <1513616405.7113.18.camel@gmx.de> <1513617866.4581.6.camel@primarydata.com> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:D2ZSBIKTF9CrDU2aB0qrSZspZ44iclSrFsLNoykqRoDmp0DIYgg 0Hcm431MGYztdqOpuTmDeK0RM6ug8q6QZ5yLFsG5mAaBIyOum/u38TMQ5eNcwbZH4BRQhmF AN7e7fmyQ7kRWubg0XqBVfp/wgxpdfOlZPlDT9O3ge4ZLu8ydg+rYjrPfn1HhO/nAlySivn RIBMi0C41h9ydffahHh2w== X-UI-Out-Filterresults: notjunk:1;V01:K0:kg+p+hn3DXI=:p8JhyW+M7ffXzlfDiK1acI QTu3q6ximAX4CYwvXUwdBUF+oNY2LoZGjbjFmEzd2PREWljNsNJcKm5G0ZKg7yqOGbEmIOrr5 oOPBX89ZzrzeYcP1kwu26bJf1gI6LQLme2SpMNSxj4wYhVrv+aFY8FwUzeaZd2qVYwc7ANYD4 91+jxsYq1K5FQDgljvHP7SpsSr27Nl4ZcUazMjzGcfXOlsbhd5onU29oKuAavVxCW7siBm0Tu aHOjlUcgm3KDqn2O4ZQFMqarIttW48p4x0yDqO9ZU/VdnH/pZa1qBdaaXa78x6EQnMiSOIUJG biRsVOthJHddxFGexx4EniT/qi3Lz9Weq0KaQ9jk2Uu3chFl30HyZ70AsBmKRcocNlLT9Pah+ 7LUb3/KWH+/lV7sGCUT+aRzdoEFBuaj/sjQGWw42/1F/vVbJnRW7/L9rXtROBxDmYMYW3huWn Q85zDesvfPhcsAsojcJ6PzcIflOzfMPQF5WleZswJ+vPiVzGEZrwv4EIWEU4+KOBfYxu+ys5i inMCuJK91NKtbq8XRNJjqtTpP3yTFAaMJxwrO0ODmkc2f9NLRVFrBQ8ipixng4znO3f6GqQfa PjeG2rWgvQ0+Zh3XZ2aatItSIQBygYLc7cgic8a4WpKN+9wPLJN6U3ebaw0KW+Cd2gpCHEwLn YwYeppWrszrMYCiRabzMb7h5U7KziUQEHzfT4S51AZV9df0fBjNjabxl3msHgaHeNYjiMyiwz H/YDahfkjjQ4wSODRuxJkoroquLR9R/gB66R6HuCbkucq4ll7+McMYJThVC2HElh73PPoy/U6 XYSglgfcypOBtm9Flve8yGeaHFH35X7au4Y33xhefGcF+G+qhg= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 846 Lines: 20 On Mon, 2017-12-18 at 17:24 +0000, Trond Myklebust wrote: > On Mon, 2017-12-18 at 18:00 +0100, Mike Galbraith wrote: > > On Mon, 2017-12-18 at 11:35 -0500, J. Bruce Fields wrote: > > > > > > Like I say, I don't really understand the issues here, so it's more > > > a > > > question than an objection.... (I don't know any reason a > > > cond_resched() would be bad there.) > > > > Think of it this way: what all can be queued up behind that kworker > > that is hogging CPU for huge swaths of time? It's not only userspace > > that suffers. > > > > Any cond_sched() belongs in the loop in nfs_commit_release_pages() > (where it can be mitigated) rather than in a function whose purpose is > to free memory. There is no reason to call it from the writeback or > readpages code. (this is why bandaid didn't come equipped with changelog etc:)