From owner-freebsd-arch@FreeBSD.ORG Mon Jun 11 09:22:34 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A73C81065672 for ; Mon, 11 Jun 2012 09:22:34 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2098FC23 for ; Mon, 11 Jun 2012 09:22:34 +0000 (UTC) Received: from [192.168.2.111] (host86-182-204-28.range86-182.btcentralplus.com [86.182.204.28]) by cyrus.watson.org (Postfix) with ESMTPSA id BA57646B0D; Mon, 11 Jun 2012 05:22:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <20120611091811.GA2337@deviant.kiev.zoral.com.ua> Date: Mon, 11 Jun 2012 10:22:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120606165115.GQ85127@deviant.kiev.zoral.com.ua> <20120611091811.GA2337@deviant.kiev.zoral.com.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1257) Cc: arch@freebsd.org Subject: Re: Fast gettimeofday(2) and clock_gettime(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 09:22:34 -0000 On 11 Jun 2012, at 10:18, Konstantin Belousov wrote: >> 3) For the purposes of adaptive mutexes in userspace, it really would = be=20 >> quite >> nice to know whether remote threads are running or not, in the same = way >> that cheap access to remote thread run state in the kernel makes = for much >> more efficient adaptive spinning. I wonder if we could use this=20 >> mechanism >> for that purpose as well. I guess for now, at least, you're using = a=20 >> single >> global page, but in the future, per-process pages might be quite >> beneficial. >=20 > The per-process page looks almost undoable. I think that what could be > made working, although with some hacks, is per-CPU page, and the page > content update on context switch. This could benefit trivial system = calls > like getpid(), getppid() and others, but obviously cause increased = context > switch latency. >=20 > Per-CPU page would then solve the proposal of having an indicator of > other threads running. I am not sure how much do we care of the = potential > information leak there. FYI, the FreeBSD/MIPS kernel already makes use of an MD per-thread page = using a reserved TLB entry switched on each kernel context switch. = Interestingly, this model effectively conflicts (semantically) with the = higher-level MI per-CPU mechanism. It would be nice to unify across the = layers within the kernel, even if not all the way to userspace. Robert=