From owner-freebsd-arch Mon Dec 31 5:41:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prg.traveller.cz (prg.traveller.cz [193.85.2.77]) by hub.freebsd.org (Postfix) with ESMTP id 5AF4637B42F for ; Mon, 31 Dec 2001 05:41:32 -0800 (PST) Received: from prg.traveller.cz (localhost [127.0.0.1]) by prg.traveller.cz (8.12.1[KQ-CZ](1)/8.12.1/pukvis) with ESMTP id fBVDfQlk033352; Mon, 31 Dec 2001 14:41:26 +0100 (CET) Received: from localhost (mime@localhost) by prg.traveller.cz (8.12.1[KQ-CZ](1)/pukvis) with ESMTP id fBVDfQLb033349; Mon, 31 Dec 2001 14:41:26 +0100 (CET) Date: Mon, 31 Dec 2001 14:41:26 +0100 (CET) From: Michal Mertl To: Bruce Evans Cc: Alfred Perlstein , Matthew Dillon , Subject: Re: 64 bit counters In-Reply-To: <20011231234620.O6481-100000@gamplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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 :-). > Bruce > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message