From owner-freebsd-arch Mon Dec 31 12:40: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 65AAB37B439 for ; Mon, 31 Dec 2001 12:39:26 -0800 (PST) Received: (qmail 2761 invoked from network); 31 Dec 2001 20:39:24 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 31 Dec 2001 20:39:24 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 31 Dec 2001 12:39:13 -0800 (PST) From: John Baldwin To: Michal Mertl Subject: Re: 64 bit counters Cc: arch@FreeBSD.ORG, Matthew Dillon , Alfred Perlstein , Bruce Evans 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 On 31-Dec-01 Michal Mertl wrote: > On Mon, 31 Dec 2001, Bruce Evans wrote: > >> On Sat, 29 Dec 2001, Alfred Perlstein wrote: >> >> > * Michal Mertl [011229 18:49] wrote: >> > > I doesn't seem too bad to me, but I do have a problem - I can't >> > > implement >> > > real atomic 64 bit operations on an i386. It shouldn't be named >> > > atomic_XXX >> > > if it isn't atomic. So that other people don't start to use it on <586 >> > > with some variable which changes fast. >> > > >> > > What about making the counters not 64 bit, but the size of biggest >> > > atomic >> > > type? Something like type u_maxatomic_t which would be 32 bit on <586 >> > > and >> > > 64 bit otherwise. There would still be problem in determining at compile >> > > time the size but we could choose the safe size if not somewhere defined >> > > otherwise. >> > > >> > > I can make changes to my local tree but how should I send them someone >> > > for >> > > review? Should I send them to arch? I tried to find the answer to this >> > > question in developers's handbook but didn't find it. >> > >> > *laff* the concept of atomic_t was initially proposed by me over >> > a year ago (i got the idea from linux) however it never seemed to >> > get done. >> >> atomic_t would be "int" if anything. I removed support for atomic >> operations on all types except "int" (and some pointers punned to int >> on i386's), and found that (on i386's) only 2 source files didn't >> compile. Both are easy to fix (one MD place used a char type for a >> set of flags that is followed by padding to a 32-bit boundary anyway, >> and one MI place uses long types which are equivalent to ints on i386's >> anyway). >> > > I've almost finished the changes to implement interface counters with > atomic_t which is either 32 bit or 64 bit. I'll finish it anyway. It can > at least be converted to atomic_add_int (instead of my WIP name > atomic_add_max and friends) and it will help someone later to be able to > get rid of giant protection. I may be wrong even with this - well if > that's going to be the case and otherwise there will be no use for my > changes, they can always be forgotten. I could take it as practice lesson > on hacking kernel sources :-). I really need to fix the atomic(9) API to use sizeof() instead of explicit types like Bruce wants. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message