Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937641AbdLRRrx convert rfc822-to-8bit (ORCPT ); Mon, 18 Dec 2017 12:47:53 -0500 Received: from mout.gmx.net ([212.227.17.22]:56410 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934240AbdLRRrs (ORCPT ); Mon, 18 Dec 2017 12:47:48 -0500 Message-ID: <1513619245.7113.45.camel@gmx.de> Subject: Re: NFS: 82ms wakeup latency 4.14-rc4 From: Mike Galbraith To: "J. Bruce Fields" Cc: lkml , Jeff Layton , linux-nfs@vger.kernel.org Date: Mon, 18 Dec 2017 18:47:25 +0100 In-Reply-To: <20171218172711.GA12454@fieldses.org> References: <1513610231.7998.13.camel@gmx.de> <1513611112.7113.1.camel@gmx.de> <20171218163559.GA11829@fieldses.org> <1513616405.7113.18.camel@gmx.de> <1513617456.7113.25.camel@gmx.de> <20171218172711.GA12454@fieldses.org> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8BIT X-Provags-ID: V03:K0:LxRLbYmEpNhsVQm+RDkmFamcWzVGUocs9uKGVJ9rJCFPAME83le Syr3we0haOG2fS/phGhtFnFSZ7MdYeOvfIcmdfjYeujgjizlliXDbYGXiK2otPaiOOSAjKd KHw6aTe/f5FiMhJjci08Dutugw9nF8EWvMWWt6pNCMA+CbF0Ug+loUv5CVcJjGZSUTmg6kE cMpwoisa5yXommJW71x3A== X-UI-Out-Filterresults: notjunk:1;V01:K0:weoX9cgL9x0=:cYpPKonSOBhAmGTLOVhXJQ evcRjC8Rl2vojgGIP5a8EDevXqsDv/b+8tLaPqNp9Xd88SjbkLw/S/1WCY9TnkhtgllJZcdqC zsKzyjQzv4oOSKgw78GId/jUYw9qqZwHBPG/tmfRJL7n5l2XlxlO2Ygy6FHNHYrCGHStcYNrD u8BfHhbKecWD8D2kwc9LLFHRVzJ5T1cRvKNVFts6wpP+kOa/NClvxZDFCx1u4pR5n6o1Jpez1 5rIJA6xt+GR7RPJHfqrKR5bLY+oZBt20tR9hmw2QeeahzL7QL0FpVsyPUIhINRt6r/mpWuWq3 s4hCojel7gU0XDk7QhaS8MQpX98fesVNhrz46fzrg1YGWdCRoeB6Ajzr9JQnst8n2i87sONGL AdUTAcy7olVu5YZEJLqbwLA/r+0OysttMAv01ikHIivfDe19aPsqs1PVJaRAOK3RYpa173bzo miF/lRqOOZQu8xiEExpvRV5HO6EwHfJ4IwqyyZurQ3c1yYS7RMvoAAopoTxMSi6i3O9UzSiIN C3dJbtL1l70giLpqP1djmQcsY3f21zEsKBWZ4M12xcjBCG2B2tqVOvxn6jsj2m6cStdrIlilc O4mBGvY6NS1ywlp1tQ+eFhUEJg2s7u2NQre+0/xa5MPX3lVtvCMgK+L7eOgxXd6GS8IS8eGuT y6PvRu9kCdvAOdvnkB+I8Bh5bwriEC4AdS5e7f99oWEiPrJ/NBkO/hJaOun51oPOVa7vUX+ua BPO3ffOKiZTZKTnyrgLuKYArp/8RpPxsO6o05zSOEYgd3iWsNYhnBOKLyLivTK0u567uiTqmy lZiVyCb+IlS8us6GILCH9lM4uhfqbMC2ytLvL8Q9JJEKLaMWoEEuHf/Pi0KCttIckCoq7L/ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1511 Lines: 32 On Mon, 2017-12-18 at 12:27 -0500, J. Bruce Fields wrote: > On Mon, Dec 18, 2017 at 06:17:36PM +0100, Mike Galbraith 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. > > > > Bah, I'm gonna sound like a damn Baptist preacher, but I gotta say, > > latency matters just as much to an enterprise NOPREEMPT kernel and its > > users as it does to a desktop kernel and its users. ?For max > > throughput, you don't want to do work in _tiny_ quantum, because you > > then lose throughput due to massive cache trashing and scheduling > > overhead, but latency still does matter, and not just a little. > > Right, what I don't understand is why kernels are still built without > preemption. Oh, that's easy.. because they absolutely SUCK at throughput, and contrary to popular belief, they do not provide anything remotely similar to deterministic behavior. ?They're better at latency, but not really all that much in general use, while being horrid at getting work done efficiently. I tried PREEMPT, but much prefer VOLUNTARY performance/efficiency. -Mike