From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 3 03:23:52 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 4073A16A46C for ; Wed, 3 Oct 2007 03:23:52 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 18B5C13C457 for ; Wed, 3 Oct 2007 03:23:51 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so5409253waf for ; Tue, 02 Oct 2007 20:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=dIGBHhIOOrrHrF8rnHU6iFVAsk42UtwSkxyx+dLcSb0=; b=mYO5xzCHHnALWOuIRO69teoKVVNP5XWX+ySTow1izNT9zXqfBwNS4eTQuDtzoLS9a8UC4Ot4Z0rB9/XgS1CGLhiHYjcp3wTofg2Ksf9szeYEWmElfgSq5Pk8P+sfR7MehIZBUEamn2CtZllrTOgABqaoAv/s5Flc9lAwdoL0sAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ED3VcOMkFw8AVxe9JftnpYWR9XLQHDNvDZ4RavZ5UaCrM+2/0naM1Sbu4tVlpFGrPiEyb7LrFLaVJFLLpAME7GHZRmqUgHzbH8xXZ5yxvdK9S7Z+U0Ue50/rTHmphxLOvPWPkQn8kbGRlkfAlgClzDxaDo7NowuLy5DKXE5eOfw= Received: by 10.114.111.1 with SMTP id j1mr3482452wac.1191381823236; Tue, 02 Oct 2007 20:23:43 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Tue, 2 Oct 2007 20:23:43 -0700 (PDT) Message-ID: Date: Tue, 2 Oct 2007 20:23:43 -0700 From: "Kip Macy" To: "Daniel Eischen" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071003015231.GJ31826@elvis.mu.org> <20071003025418.GN31826@elvis.mu.org> <20071003030943.GQ31826@elvis.mu.org> Cc: hackers@freebsd.org, Alfred Perlstein 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: Wed, 03 Oct 2007 03:23:52 -0000 On 10/2/07, Daniel Eischen wrote: > On Tue, 2 Oct 2007, Alfred Perlstein wrote: > > > * Daniel Eischen [071002 20:02] wrote: > >> On Tue, 2 Oct 2007, Alfred Perlstein wrote: > >> > >>> * 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: > >> > >> Well, yeah, but are you _really_ sure that you aren't just > >> running something that should be real-time and have priority > >> over other applications? SCHED_FIFO means you will run until > >> you relinquish the CPU (you can only do this as root). If > >> all your threads are well behaved, would this work? Have > >> you tried it? > > > > No, because it wouldn't work. How do we know when to let go > > of the cpu? In my system, the kernel tells you without polling. > > You don't have to know when to "let go of the cpu" if your > threads are well behaved (meaning they block on some event, > or have periods when they wait). They will let go of the > CPU normally. When they're busy, they will not be switched > out (unless perhaps there is an interrupt thread that needs > to run -- I'm not sure how real-time threads get scheduled > against ithreads). > > If your threads are not well behaved (CPU hogs), then that > isn't going to work because they'll probably bog down the > system. > See /sys/priority.h realtime is right below ithreads in terms of priority. One of the big motivations for gang scheduling and part of the reason why SMP guests often perform poorly is that apps / VMs don't scale well if they're descheduled from the cpu while holding a lock. -Kip