From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 4 19:38:22 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D91616A421 for ; Thu, 4 Oct 2007 19:38:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outG.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id 2437F13C474 for ; Thu, 4 Oct 2007 19:38:21 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 04 Oct 2007 12:25:24 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id D79F01265BA; Thu, 4 Oct 2007 12:25:23 -0700 (PDT) Message-ID: <47053E26.1020309@elischer.org> Date: Thu, 04 Oct 2007 12:25:26 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Attilio Rao References: <20071003015231.GJ31826@elvis.mu.org> <20071003025418.GN31826@elvis.mu.org> <3bbf2fe10710041054x1c580bb2m892bf389a70c0e6c@mail.gmail.com> In-Reply-To: <3bbf2fe10710041054x1c580bb2m892bf389a70c0e6c@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Alfred Perlstein , hackers@freebsd.org Subject: Re: Critical Sections for userland. 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: Thu, 04 Oct 2007 19:38:22 -0000 Attilio Rao wrote: > 2007/10/3, Alfred Perlstein : >> * Daniel Eischen [071002 19:46] wrote: >>> On Tue, 2 Oct 2007, Alfred Perlstein wrote: >>> >>>> Hi guys, we need critical sections for userland here. >>>> >>>> This is basically to avoid a process being switched out while holding >>>> a user level spinlock. >>> Setting the scheduling class to real-time and using SCHED_FIFO >>> and adjusting the thread priority around the lock doesn't work? >> Too heavy weight, we want to basically have this sort of code >> in userland: >> >> /* assume single threaded process for now */ >> static int is_critical; >> >> >> >> atomic_mutex_lock(); /* implies ++is_critical */ >> ...do stuff... >> atomic_mutex_unlock(); /* implies --is_critical */ >> >> We don't want two or more syscalls per lock operation. :) > > Basically, preemption in kernelspace is handled by using the > td_critnest counter which should work in this way: > - critical_enter() bumps td_critnest > - if preemption is required or an ipi arrives and the operation is > signalled with the td_owepreempt flag and will be deferred. > - once critical_exit() is called the counter is decreased. If > necessary (checking for td_critnest and td_owepreempt) the preemptive > operation happens instantanely. > > It is all very fast and highly scalable as scope of operation is > entirely per-thread so it doesn't require any lock. I think maybe you > should use a very similar scheme to this. > > Attilio > > I suggest that we map a per-thread page into the address space if it requests it. (and a per process page). The scheduler could look at it for behavioural hints when it is present. there are ways this could be done. it sort of dovetails into work other people have been considering..