From owner-freebsd-mips@FreeBSD.ORG Tue Sep 27 14:24:06 2011 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE443106566B; Tue, 27 Sep 2011 14:24:06 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2AC7A8FC17; Tue, 27 Sep 2011 14:24:05 +0000 (UTC) Received: by wyj26 with SMTP id 26so5613054wyj.13 for ; Tue, 27 Sep 2011 07:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7us3orChbTInro0z5oNt9JjWWKpmVqIxtyHSD0A9vKQ=; b=UlsnGWT9AweJaDH1FU2vcgxyx0jV8i18496ngvTHOmy++u3C2ZHJBecJbMVQd4Vm0C iWJkT8nH7deOK6k90oaHJ9GByqMpcfOP8wpON3XcB3wu9VveAfu3cIRoK2oMeQvzrThX fyI1lgFlFPwOspYXDPSEwPIG4fZLx3hg6z2rI= MIME-Version: 1.0 Received: by 10.216.159.133 with SMTP id s5mr8989170wek.27.1317131873667; Tue, 27 Sep 2011 06:57:53 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.216.179.78 with HTTP; Tue, 27 Sep 2011 06:57:53 -0700 (PDT) In-Reply-To: <201109270951.07839.jhb@freebsd.org> References: <201109270951.07839.jhb@freebsd.org> Date: Tue, 27 Sep 2011 15:57:53 +0200 X-Google-Sender-Auth: tejor1ZkVAcCdRA-1xoK-OaPEc0 Message-ID: From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-mips@freebsd.org Subject: Re: ath / 802.11n performance issues and timer code X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 14:24:06 -0000 2011/9/27 John Baldwin : > On Monday, September 26, 2011 11:36:26 pm Adrian Chadd wrote: >> .. and as a follow up (and cc'ing attillo and freebsd-mips, in case >> it's relevant to other platforms and there's a MIPS specific thing to >> fix): >> >> * 2128: mi_switch to idle >> * 2129: kern_clocksource.c:762 - ie, cpu_idleclock() has been called >> * 2130: the ath interrupt comes in >> * 2134: it's skipped for now as the idle thread is in a critical section >> * 2136: kern_clocksource.c:266 - ie, getnextcpuevent(), inside > cpu_idleclock(). >> >> What I bet is happening is this race between the critical section + >> cpu_idleclock() and the ath0 interrupt: >> >> * idle gets scheduled >> * critical_enter() is called in the mips cpu_idle() routine >> * the ath interrupt comes in here and gets handled, but since we're in >> a critical section, it won't preempt things >> * the cpu_idleclock() code completes without releasing the preemption, >> and the only thing that wakes up from that wait is the next interrupt >> (clock, arge0, etc.) > > I think this is a mips-specific bug, though it may be well to audit all t= he > cpu_idle() implementations. =C2=A0On x86 the idle hooks all check sched_r= unnable() > with interrupts disabled and then atomically re-enable interrupts and sle= ep > only if that is false, e.g.: > > static void > cpu_idle_hlt(int busy) > { > =C2=A0 =C2=A0 =C2=A0 =C2=A0int *state; > > =C2=A0 =C2=A0 =C2=A0 =C2=A0state =3D (int *)PCPU_PTR(monitorbuf); > =C2=A0 =C2=A0 =C2=A0 =C2=A0*state =3D STATE_SLEEPING; > =C2=A0 =C2=A0 =C2=A0 =C2=A0/* > =C2=A0 =C2=A0 =C2=A0 =C2=A0 * We must absolutely guarentee that hlt is th= e next instruction > =C2=A0 =C2=A0 =C2=A0 =C2=A0 * after sti or we introduce a timing window. > =C2=A0 =C2=A0 =C2=A0 =C2=A0 */ > =C2=A0 =C2=A0 =C2=A0 =C2=A0disable_intr(); > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (sched_runnable()) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enable_intr(); > =C2=A0 =C2=A0 =C2=A0 =C2=A0else > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__asm __volatile("= sti; hlt"); > =C2=A0 =C2=A0 =C2=A0 =C2=A0*state =3D STATE_RUNNING; > } > > I don't know if it is possible to do the same thing with the mips "wait" > instruction. After thinking about it I think this check is unnecessary. sti, infact, doesn't enable interrupts before hlt (it just sets IF=3D1) but interrupts can fire only after hlt, thus I don't think a preemption or interrupts firing there can be possible. This patch: http://www.freebsd.org/~attilio/stihlt.patch removes the check and also replaces simple 'hlt' instruction insertion in C code with the already defined halt(). I still have to go through Adrian's e-mails so I'm not sure if the logic you post is going to help him or not, but this is my thinking on the x86 implementation (specifically). Comments? Attilio --=20 Peace can only be achieved by understanding - A. Einstein