From owner-freebsd-arch@FreeBSD.ORG Thu Aug 18 17:25:25 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1444916A41F for ; Thu, 18 Aug 2005 17:25:25 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 275C543D69 for ; Thu, 18 Aug 2005 17:25:22 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 88045 invoked from network); 18 Aug 2005 17:05:32 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 18 Aug 2005 17:05:32 -0000 Message-ID: <4304C485.AC251A46@freebsd.org> Date: Thu, 18 Aug 2005 19:25:25 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin References: <42F9ECF2.8080809@freebsd.org> <200508181023.05929.jhb@FreeBSD.org> <20050818095546.A91965@xorpc.icir.org> <200508181312.21512.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org, gnn@FreeBSD.org Subject: Re: Special schedulers, one CPU only kernel, one only userland X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2005 17:25:25 -0000 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