Return-Path: linux-nfs-owner@vger.kernel.org Received: from mail-qg0-f41.google.com ([209.85.192.41]:62489 "EHLO mail-qg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932073AbaLBTSR (ORCPT ); Tue, 2 Dec 2014 14:18:17 -0500 Date: Tue, 2 Dec 2014 14:18:14 -0500 From: Tejun Heo To: Jeff Layton Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, Al Viro Subject: Re: [RFC PATCH 00/14] nfsd/sunrpc: add support for a workqueue-based nfsd Message-ID: <20141202191814.GK10918@htj.dyndns.org> References: <1417544663-13299-1-git-send-email-jlayton@primarydata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1417544663-13299-1-git-send-email-jlayton@primarydata.com> Sender: linux-nfs-owner@vger.kernel.org List-ID: Hello, Jeff. On Tue, Dec 02, 2014 at 01:24:09PM -0500, Jeff Layton wrote: > 2) get some insight about the latency from those with a better > understanding of the CMWQ code. Any thoughts as to why we might be > seeing such high latency here? Any ideas of what we can do about it? The latency is prolly from concurrency management. Work items which participate in concurrency management (the ones on per-cpu workqueues w/o WQ_CPU_INTENSIVE set) tend to get penalized on latency side quite a bit as the "run" durations for all such work items end up being serialized on the cpu. Setting WQ_CPU_INTENSIVE on the workqueue disables concurrency management and so does making the workqueue unbound. If strict cpu locality is likely to be beneficial and each work item isn't likely to consume huge amount of cpu cycles, WQ_CPU_INTENSIVE would fit better; otherwise, WQ_UNBOUND to let the scheduler do its thing. Thanks. -- tejun