Date: Thu, 18 Aug 2005 19:25:25 +0200 From: Andre Oppermann <andre@freebsd.org> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org, gnn@FreeBSD.org Subject: Re: Special schedulers, one CPU only kernel, one only userland Message-ID: <4304C485.AC251A46@freebsd.org> References: <42F9ECF2.8080809@freebsd.org> <200508181023.05929.jhb@FreeBSD.org> <20050818095546.A91965@xorpc.icir.org> <200508181312.21512.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
To reverse-highjack my thread again. Here are some excerpts from a direct email response to Luigi for the record of -arch. Luigi> Apart from pinning one thread to a given CPU, the SMP architecture Luigi> of FreeBSD 5/6 will not help in doing what you want because it will Luigi> still force you to pay the locking overhead compared to 4.x. My idea is/was to move to much less expensive UP locks within the kernel if the CPU's can be split into kernel and userland. Maybe not all of them. Some synchronization would still be required between those two CPU's but at least all in the critical path I care about [are inexpensive]. Luigi> ... My workload for this scenarion is routing and running routing protocols. Routing is not something that is really SMP scaleable unless you have truely distributed architecture. However some routing protocols can get quite CPU intensive at times and with my split SMP I get both worlds. The kernel CPU can continue forwarding packets and the user CPU can recalculate all the routing tables. Only from time to time those two have to meet somewhere. When packets for userland arrive or the routing daemon is sending packets. And of course kernel FIB updates. But compared to the number of transactions happening overall these boundary crossings are just a little tiny fraction of 0.00001%. I'd rather have optimized the other 99.99999% of the events happening per second by 50% each. And I'm willing to pay even a hefty price for the boundary crossing as long as it is not too hefty on the kernel side. It can take as long as it wants on the userland side. I'm fine with suspending the userland CPU entirely while it waits for the kernel. Would be nice if it could switch to another task but I don't care. ... -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4304C485.AC251A46>