From owner-freebsd-arch@FreeBSD.ORG Tue Nov 14 11:56:48 2006 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 2247416A415 for ; Tue, 14 Nov 2006 11:56:48 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 879C543D46 for ; Tue, 14 Nov 2006 11:56:47 +0000 (GMT) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gjwtu-0002h0-5T for freebsd-arch@freebsd.org; Tue, 14 Nov 2006 12:56:26 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Nov 2006 12:56:26 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Nov 2006 12:56:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Tue, 14 Nov 2006 12:55:57 +0100 Lines: 16 Message-ID: References: <7105.1163451221@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.4 (X11/20060625) In-Reply-To: <7105.1163451221@critter.freebsd.dk> Sender: news Subject: Re: a proposed callout API 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: Tue, 14 Nov 2006 11:56:48 -0000 Poul-Henning Kamp wrote: ... > 4. We execute all callouts on one CPU only. ... > Short callouts, less than 2 seconds, will be stored in a binary > heap (A tree where a node is numerically lower than its parents.) > > The depth of the heap is Log2(nodes) and there are very efficient > ways to store and access the heap. > > Locking will be with one mutex for the heap. Won't that retain the 1-cpu-only "feature"? Maybe make NCPU or NCPU/2 groups and fill them round-robin?