From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 1 10:31:02 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BD17106564A; Sat, 1 Oct 2011 10:31:02 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 692B58FC0C; Sat, 1 Oct 2011 10:31:01 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so3314857bkb.13 for ; Sat, 01 Oct 2011 03:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=5xBAlWh4h/uxYigaMm1b0UeQcGOZEI9fMWKl6yZKXHo=; b=RDMS4ucCJXZHXA65CYU6W4oI3xb/y4ecV43vgf8yORLcDXvXpelpoAt0zkAVx9Z04E jJSrk1m3eJB2ryik7pgHPFt7y28ZJuHxQRkSLD/wn3VMvy6s2pzzeHWNf22aXWDI2XBq KEaoN1XJ51e/JwdaH7CX8FIR/jFD4OFUgJAVU= Received: by 10.204.147.141 with SMTP id l13mr124199bkv.73.1317465060222; Sat, 01 Oct 2011 03:31:00 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id t13sm1793162fae.0.2011.10.01.03.30.58 (version=SSLv3 cipher=OTHER); Sat, 01 Oct 2011 03:30:59 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E86EBD5.9070705@FreeBSD.org> Date: Sat, 01 Oct 2011 13:30:45 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Adrian Chadd References: <4E86DC86.3040204@FreeBSD.org> <4E86E20B.7000703@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: how are callouts handled in cpu_idle() ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 10:31:02 -0000 Adrian Chadd wrote: > Right. Hm, what about for i386/amd64 cases we call intr_disable() > before the critical_enter and idleclock, then re-enable either just > before the wait/halt call (like it is now) or just after the > sched_running check (just like it is now.) > > That way a filter handler which schedules a callout gets called correctly? As I have described, that can fix only part of the problems (only delayed shots, but not too early shots). It still won't allow to reliably use callouts from the interrupt filter handlers. Also I've just recalled one possible issue from that. cpu_idleclock() calls binuptime() to get present system time to properly reprogram timer hardware. In most cases binuptime() is quite undemanding call to be called anywhere, but at least on some kinds of sparc64 hardware it uses IPI to read time counter from another CPU, because of assumption that CPUs may not be synchronized. I hate that, but that's fact. Attempt to wait for IPI with interrupt disabled may cause dead lock between several CPUs. Respecting that, in event timers subsystem I was trying to avoid calling binuptime() with disabled interrupts. To be honest, sparc64 doesn't have cpu_idle() function now to all, but if we speaking about general (perfect) case, we should either continue avoid this, or deny things like what sparc64 does. -- Alexander Motin