Date: Sun, 13 Jan 2002 21:25:34 +0100 (CET) From: Michal Mertl <mime@traveller.cz> To: arch@freebsd.org Subject: 64 bit counters again Message-ID: <Pine.BSF.4.41.0201132057560.62182-100000@prg.traveller.cz>
next in thread | raw e-mail | index | archive | help
If I'm writing to this forum about inappropriate issue, you could tell me,
rather than just ignore me.
But anyway I continued on some work on STABLE (but believe lot of my work
could be used on CURRENT after some modification) and get kernel and world
building with 64 bit counters on network interfaces (struct if_data)
and in protocols (struct ipstat, tcpstat, udpstat, icmpstat, igmpstat).
I implemented new machine dependant include file (but it could be quite
easily made MI with some cpp magic I believe) and atomic_??_quad
functions (conditionally included).
I have new API for counters which resembles lot atomic?? functions but has
one more parameter. That parametr is used to tell in which part of kernel
source is the variable and the functions then does either atomic or
"normal" operation on the counter. This variable needn't to be defined
this way, it could also be used to directly tell what kind of operation is
required but I believe this way it's more flexible.
example:
-------------------------
static __inline void syscntr_add(const int loc, volatile u_int64_t *p,
u_int32_t v)
{
switch (loc) {
case CNTR_NET_PROTO:
case CNTR_NET_DEV:
#if defined(SYSCNTR_ASM)
__asm __volatile ("#syscntr_add_quad
addl %1,(%0)
adcl $0,4(%0)"
:
: "S" (p), "q" (v));
#else
*p+=v;
#endif
break;
case CNTR_SOMETHING:
atomic_add_quad(p,v);
break;
default:
atomic_add_quad(p,v);
}
}
------------------------
It should always inline to either call to atomic function (in kernel
modules and external programs) or the simple operation.
I did small benchmark (on UP but will soon test hopefully on SMP and let
you know). I moved 256MB trhough 100FDX and measured the throughput and
load (using vmstat). I dind't notice any performance difference between
32/64 bit, atomic/non-atomic functions (but atomic was without lock
istructions).
Before you start telling it's the wrong way to go (on CURRENT at least) I
can see there may be other modes of operation of the functions, PER_CPU
data of whatever - using something like the API provided would hide it
nicely. Once something is in a subsystem which isn't under giant or some
other change with locking or such you would change just one place and the
variables would be kept accessed the right way.
In case someone wants to see the whole thing it's at
http://home.eunet.cz/mime/syscntr.patch.0113.gz
I know there are some style problems - at least too-long lines. I have
them noted down and I'm ready to split them. Only I don't know what is the
right maximum length and how much spaces I should count for tabs.
I also noticed, that some drivers do define similar counters like if_data
in their sources - if_ar.c and others - which is for netgraph I believe. I
could quite easily change these variables to the newly defined type too
but I don't know, if one can easily change variable type in netgraph - I
didn't want to violate some standard. Also there are several drivers
(bge) which use dot3stats variables from if_mib for error counting. These
are also 32 bits.
--
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.0201132057560.62182-100000>