From owner-freebsd-arch Wed Jan 2 15:23:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 12CA137B419; Wed, 2 Jan 2002 15:23:54 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g02NNjt60197; Wed, 2 Jan 2002 15:23:45 -0800 (PST) (envelope-from dillon) Date: Wed, 2 Jan 2002 15:23:45 -0800 (PST) From: Matthew Dillon Message-Id: <200201022323.g02NNjt60197@apollo.backplane.com> To: Peter Jeremy Cc: Michal Mertl , Bruce Evans , Mike Smith , Bernd Walter , arch@FreeBSD.ORG Subject: Re: When to use atomic_ functions? (was: 64 bit counters) References: <200201012349.g01NnKA40071@apollo.backplane.com> <20020103095701.B561@gsmx07.alcatel.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :This depends on how it is implemented. Obviously : int counter[NCPUS]; :will be just as expensive as performing atomic operations, but no-one :in their right mind would do that. One approach is to aggregate all :the per-CPU counters into a single region of KVM and arrange for that :KVM to be mapped to different physical memory for each CPU. (Solaris :does or did this). This means that the code to update the counter :doesn't need to know whether a counter is per-CPU or not. : :The code to read the counters _does_ need to know that the counters :are per-CPU and have to sum all the individual counters - which is :more expensive than a straight read, but is normally far less frequent. : :Peter Something like galloc()/gfree(). offset = galloc(bytes); /* allocate space in all cpu's per-cpu struct*/ gfree(offset, bytes); /* return previously reserved space */ And then macros to read and write it. global_int(offset) /* returns address of global int @ offset */ global_quad(offset) /* returns address of global int @ offset */ e.g. ++*global_quad(ifc->counter_off); Which GCC ought to be able to optimize fairly easily. This isn't a recommendation, just one way we could do it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message