From owner-freebsd-arch Fri Jan 4 4:58:35 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 2EB0037B417 for ; Fri, 4 Jan 2002 04:58:31 -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 g04CwTlk041836 for ; Fri, 4 Jan 2002 13:58:29 +0100 (CET) Received: from localhost (mime@localhost) by prg.traveller.cz (8.12.1[KQ-CZ](1)/pukvis) with ESMTP id g04CwTQR041833 for ; Fri, 4 Jan 2002 13:58:29 +0100 (CET) Date: Fri, 4 Jan 2002 13:58:29 +0100 (CET) From: Michal Mertl To: arch@freebsd.org Subject: back to STABLE 64 bit counters 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 I can't say much about the recent discussions about solvning the problem on current but my focus is primarily on production machines running 4.X. I'd like to ask some questions. Talking _STABLE_ only. 4.X runs UP on i386 and Alpha. SMP is available on >=i586. Right? Current interface and protocol counters are defined as unsigned int or unsigned long (64 bit on Alpha?) and accessed with regular C operations. I won't talk much about Alpha because I don't know anything about that. But because it's 64 bit, it shouldn't make much difference if we use 64 bits instead of 32 bit AFAIK. Does i386 should work with current STABLE ipmlementationeven in SMP? If yes, why? Is it because of some big locking? I think compiler can sometimes generate read/modify/write operations for i+=j. If it is so, I don't think there will be much difference even using compiler builtin long long. Even if there was bigger chance of u_int64_t operations (e.g. addl&adcl) be interrupted I think that with small changes of values even multiple operations taking place at the same time shouldn't result in bad value (in case of addl&adcl). To ensure only small changes are happening we could have functions like counter_add(u_int64_t *, u_int32_t). I'll try to apply my patch (one using lock;cmpxchg8b) to STABLE SMP machine and see if it gets noticealy slower/will have higher cpu usage with lots of interrupts and tell you the results. If I don't see the slowdown I think we could really use atomic ops (and I suppose on UP Alpha just normal addition). If there's good chance the talks about CURRENT can lead to working implementation on STABLE in foreseeable future I don't care that much but otherwise I vote for implementing these on STABLE differently. -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message