Date: Mon, 31 Dec 2001 12:39:13 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Michal Mertl <mime@traveller.cz> Cc: arch@FreeBSD.ORG, Matthew Dillon <dillon@apollo.backplane.com>, Alfred Perlstein <bright@mu.org>, Bruce Evans <bde@zeta.org.au> Subject: Re: 64 bit counters Message-ID: <XFMail.011231123913.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.41.0112311436520.16032-100000@prg.traveller.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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 :-). I really need to fix the atomic(9) API to use sizeof() instead of explicit types like Bruce wants. :) -- John Baldwin <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011231123913.jhb>