Date: Mon, 6 Apr 2009 13:09:09 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Barney Cordoba <barney_cordoba@yahoo.com> Cc: freebsd-net@freebsd.org, Ivan Voras <ivoras@freebsd.org> Subject: Re: Advice on a multithreaded netisr patch? Message-ID: <alpine.BSF.2.00.0904061300160.34905@fledge.watson.org> In-Reply-To: <86599.63596.qm@web63904.mail.re1.yahoo.com> References: <86599.63596.qm@web63904.mail.re1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 6 Apr 2009, Barney Cordoba wrote: > Is there a way to give a kernel thread exclusive use of a core? I know you > can pin a kernel thread with sched_bind(), but is there a way to keep other > threads from using the core? On an 8 core system it almost seems that the > randomness of more cores is a negative in some situations. > > Also, I've noticed that calling sched_bind() during bootup is a bad thing in > that it locks the system. I'm not certain but I suspect its the thread_lock > that is the culprit. Is there a clean way to determine that its safe to lock > curthread and do a cpu bind? There isn't an interface to cleanly express "Use CPUs 4-7 for only network processing". You can configure the system this way using the cpuset command (including directing the low-level interrupts to specific CPUs in 8.x), but if we think this is going to be a frequently desired policy, a bit more abstraction will be required. I'm not familiar with the problem you're seeing with sched_bind() -- I'm using it from within some of my code without a problem, and that's fairly early in the boot. A number of deadlocks are possible if one isn't very careful early in the boot though, so I might look specifically for some of those: if you migrate a thread to a CPU that isn't yet started, it won't be able to run until the CPU has started. This means it's important not to migrate threads that might lead to priority version-like deadlocks: - Be careful not to migrate threads that hold locks the system requires to get to the point where multiple CPUs run. - Be careful not to migrate threads that will signal a resource being available, such as a device driver, required to get to the point where multiple CPUs run. - Be careful not to migrate the main boot thread. Could you be running into one of those cases? Usually they're fairly easy to diagnose using DDB, if you can get into it, because you can see what the main boot thread is waiting for, and reason about what's holding it. Are you able to get into DDB when this occurs? (Perhaps using an NMI?) Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0904061300160.34905>