| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20141202191814.GK10918@htj.dyndns.org> Date: Tue, 2 Dec 2014 14:18:14 -0500 From: Tejun Heo <tj@...nel.org> To: Jeff Layton <jlayton@...marydata.com> Cc: linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk> Subject: Re: [RFC PATCH 00/14] nfsd/sunrpc: add support for a workqueue-based nfsd 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists