From owner-freebsd-alpha Fri Dec 15 13:20:41 2000 From owner-freebsd-alpha@FreeBSD.ORG Fri Dec 15 13:20:35 2000 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id CF4BD37B6AE for ; Fri, 15 Dec 2000 13:19:29 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBFLJ6E28509; Fri, 15 Dec 2000 13:19:06 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001215210136.C62048@cicely5.cicely.de> Date: Fri, 15 Dec 2000 13:19:24 -0800 (PST) From: John Baldwin To: Bernd Walter Subject: Re: mutex/ithread jitters? Cc: alpha@FreeBSD.org, Matthew Jacob , Andrew Gallatin , =?iso-8859-1?Q?G=E9rard_Roudier?= Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 15-Dec-00 Bernd Walter wrote: > On Thu, Dec 14, 2000 at 10:29:38PM +0100, Gérard Roudier wrote: >> >> >> On Thu, 14 Dec 2000, Andrew Gallatin wrote: >> >> > John Baldwin writes: >> > > >> > > Sounds like lost interrupts. Possibly the interrupt isn't being >> > > enabled >> > > properly after the ithread finishes running the handler. >> > >> > Maybe it is time to accept defeat on squelching interrupts at their source >> > and leave the IPL raised until the handler is run? >> >> I am not an arch. guy and I will be fixed by jhb for sure :). Thanks by >> advance Jhon for teaching me. :) >> >> My understanding is that Alpha is actually IPL based and masking using >> actual level will kill most advantages if threading interrupts, at least >> for level sensitive. My probably false understanding let me think that >> result will be increase of interrupt latency without any gain in anything >> by threading interrupt handlers. > > In my understanding the reason for implementing ithread was not to get > a better response time but it is neccessary to make use of mutexes for > interupt processing. > Maybe it's better schedule an ithread only if we need to block which > should be unlikely if designed properly and keep IPL raised if > sensefull for the platform. This is sort of what light weight context switches for ithreads will do. > But I'm far away from being capable of implementing this. > > Anyway - if the 4100 has a similar behavour as the PC164 had I'm > more willing to believe that the PC164 is in reality not broken. > I fact my PC164 masked ints fine several times until it stoped which > sounds similar to what is being said for the 4100. > > Another point is that there are lots of MBs in tsunami_intr_enable/disable > especialy the dups are questionable - what's the reason not trusting a > single one? > But I can't see where writing to hardware is enshured - are the registers > marked non-cacheable - but then why an mb? > I asume 4100 is tsunami based as I can't find any reference in > alpha/dec_kn300.c for defining of platform.intr_disable/enable. Good question. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message