From owner-freebsd-arch Sun Jan 13 12:25:42 2002 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 96C9F37B405 for ; Sun, 13 Jan 2002 12:25:35 -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 g0DKPYle063133 for ; Sun, 13 Jan 2002 21:25:34 +0100 (CET) Received: from localhost (mime@localhost) by prg.traveller.cz (8.12.1[KQ-CZ](1)/pukvis) with ESMTP id g0DKPYHD063130 for ; Sun, 13 Jan 2002 21:25:34 +0100 (CET) Date: Sun, 13 Jan 2002 21:25:34 +0100 (CET) From: Michal Mertl To: arch@freebsd.org Subject: 64 bit counters again 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 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