From owner-svn-src-all@FreeBSD.ORG Mon Feb 1 08:30:40 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B24A7106566B; Mon, 1 Feb 2010 08:30:40 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id 55F5E8FC17; Mon, 1 Feb 2010 08:30:40 +0000 (UTC) Received: by iwn36 with SMTP id 36so4455957iwn.3 for ; Mon, 01 Feb 2010 00:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=lFehRuOYoKlh+l7Sjv3OieVIMIg10Ue7WEe7cjbb4yo=; b=OwCC7b6hX2m0ZuT3NgQNnnafyJqwplmAbmN2hpJrpJrqEWJG7r4oKYMWMrlNDLSeea oI9TwUF8GdZqxw82atW4vk3b5SMWEhMyxgHlSKXu9M3ZNpR2/2Nwh+OF3MztlhCJMcLb SUlhtema8uQywGaiEvfU11AeurICRsWh80DuE= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=eXj3SJblcQJd3T6wcsSjuv+cT7JIqkXXkJrjDxtp3b3zjAafarYOHpqwGC1uFKKMpz 4P/qwP/9/b54iZ7PW5pBjMXt+8Cgdz/OSc9PkdFxSusDx9v6mGEFL0GTDXifsvG9kcGX WAcMN81Cyz5Ffz4TVnJTFu562WcyZMV3pHXPc= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.146.2 with SMTP id f2mr473971ibv.23.1265013039465; Mon, 01 Feb 2010 00:30:39 -0800 (PST) In-Reply-To: <20100130164145.GB77522@alchemy.franken.de> References: <201001231554.o0NFsMbx049837@svn.freebsd.org> <3bbf2fe11001252310r408a6be4j9bc42618394b3e3d@mail.gmail.com> <20100127215904.GF40779@alchemy.franken.de> <3bbf2fe11001280216p705ed94ev61abc4be654f8cc1@mail.gmail.com> <20100130144036.GA77522@alchemy.franken.de> <3bbf2fe11001300722v7dc4e53cvc94cddd60997c79b@mail.gmail.com> <20100130164145.GB77522@alchemy.franken.de> Date: Mon, 1 Feb 2010 09:30:39 +0100 X-Google-Sender-Auth: 5fb25c7c3b8ca849 Message-ID: <3bbf2fe11002010030j65c6cecdxb82ebf45a13abfc7@mail.gmail.com> From: Attilio Rao To: Marius Strobl Content-Type: text/plain; charset=UTF-8 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Rob Farmer , src-committers@freebsd.org Subject: Re: svn commit: r202889 - head/sys/kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 08:30:40 -0000 2010/1/30 Marius Strobl : > On Sat, Jan 30, 2010 at 04:22:47PM +0100, Attilio Rao wrote: >> 2010/1/30 Marius Strobl : >> > >> > I think the idea behind using sched_lock in the sparc64 code is >> > to piggyback on it for protecting the pmap and take advantage of >> > the fact that it's held across cpu_switch() anyway. If that's >> > correct it should be possible to replace it with a separate >> > spinlock dedicated to protecting the pmap or given that due to >> > the macro madness involved in mtx_{,un}lock_spin() it's hard to >> > properly call these from asm by calling spinlock_{enter,exit}() >> > directly. >> >> Even if that is the case there is no reason to not call >> thread_lock()/thread_unlock() (which will acquire the correct >> sched_lock or do the handover in the sched_4bsd in the right way) and >> keep an unified spinlock in order to keep cpu_switch() simple and >> still offering pmap protection over context switches. >> > > It's not clear to me what threads to use in order to get this > to work the right way, for pmap_release() I'd use curthread and > for pmap_activate() I'd just pass td on to thread_{,un}lock()? > Whould the general approach of using thread_{,un}lock() for pmap > protection also do the right thing in case of ULE? I loooked briefly at the protected paths and I guess what you really want is to use a dedicated global spinlock (because you are going to access to the pmap of all CPUs, not only the one where you are running into) which doesn't necessary need to be sched_lock (cpushead is not sched_lock protected btw). Maybe something more fancy may be done, but that's simple enough and working. Attilio -- Peace can only be achieved by understanding - A. Einstein