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: <x494njzxdd9.fsf@segfault.boston.devel.redhat.com> Date: Thu, 06 Dec 2012 13:08:18 -0500 From: Jeff Moyer <jmoyer@...hat.com> To: Tejun Heo <tj@...nel.org> Cc: Jens Axboe <jaxboe@...ionio.com>, "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>, "linux-mm\@kvack.org" <linux-mm@...ck.org>, Zach Brown <zab@...hat.com>, Peter Zijlstra <pzijlstr@...hat.com>, Ingo <mingo@...hat.com> Subject: Re: [patch,v2] bdi: add a user-tunable cpu_list for the bdi flusher threads Tejun Heo <tj@...nel.org> writes: > Hmmm... cpu binding usually is done by kthread_bind() or explicit > set_cpus_allowed_ptr() by the kthread itself. The node part of the > API was added later because there was no way to control where the > stack is allocated and we often ended up with kthreads which are bound > to a CPU with stack on a remote node. > > I don't know. @node usually controls memory allocation and it could > be surprising for it to control cpu binding, especially because most > kthreads which are bound to CPU[s] require explicit affinity > management as CPUs go up and down. I don't know. Maybe I'm just too > used to the existing interface. OK, I can understand this line of reasoning. > As for the original patch, I think it's a bit too much to expose to > userland. It's probably a good idea to bind the flusher to the local > node but do we really need to expose an interface to let userland > control the affinity directly? Do we actually have a use case at > hand? Yeah, folks pinning realtime processes to a particular cpu don't want the flusher threads interfering with their latency. I don't have any performance numbers on hand to convince you of the benefit, though. Cheers, Jeff -- 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