Date: Mon, 31 Dec 2001 14:41:26 +0100 (CET) From: Michal Mertl <mime@traveller.cz> To: Bruce Evans <bde@zeta.org.au> Cc: Alfred Perlstein <bright@mu.org>, Matthew Dillon <dillon@apollo.backplane.com>, <arch@FreeBSD.ORG> Subject: Re: 64 bit counters Message-ID: <Pine.BSF.4.41.0112311436520.16032-100000@prg.traveller.cz> In-Reply-To: <20011231234620.O6481-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 31 Dec 2001, Bruce Evans wrote: > On Sat, 29 Dec 2001, Alfred Perlstein wrote: > > > * Michal Mertl <mime@traveller.cz> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.41.0112311436520.16032-100000>