Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754603AbYLIRIt (ORCPT ); Tue, 9 Dec 2008 12:08:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752473AbYLIRIl (ORCPT ); Tue, 9 Dec 2008 12:08:41 -0500 Received: from qw-out-2122.google.com ([74.125.92.27]:65285 "EHLO qw-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750979AbYLIRIj (ORCPT ); Tue, 9 Dec 2008 12:08:39 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=MjHKfjeEMfjcaZ8ge8NAus3k3ztEBrrgA8zrrG0fpB8m9WKbr0IQIpZcF3D4Uc1ZFt wLqKw93M3I0ZMMOAA+MMWOn70+WZD1UVKR/sep1KHnzUvOMz0NsSwx0wdrkIcAsjfFdf gW24GFBM0layHwuL2L3LAg/sSsWTqcFPA1wPs= Message-ID: Date: Tue, 9 Dec 2008 18:08:38 +0100 From: "=?ISO-8859-1?Q?Fr=E9d=E9ric_Weisbecker?=" To: "Steven Rostedt" Subject: Re: [ANNOUNCE] The -rt git tree Cc: LKML , linux-rt-users , "Peter Zijlstra" , "Clark Williams" , "Ingo Molnar" , "Thomas Gleixner" , "Arnaldo Carvalho de Melo" , "Gregory Haskins" , "Darren Hart" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5963 Lines: 151 2008/12/9 Steven Rostedt : > > The -rt branch has been static for some time. We are sorry about that, > but most of those that maintain it have been working on other parts of the > kernel. Mostly new mainline work. > > People have also been asking about having an -rt git tree. Well, it is > time to create one. > > We have started working on an -rt git tree. Note, it is currently broken > and not ready for use. An announcement will be made when it is ready. This > email is only to let people know that we are currently actively working on > the new -rt tree. > > The git tree is located here: > > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-rt.git > > The branches include: > > linus - the mainline branch that the rest is based on > rt-master - all the rt/* branches merged into one > master - rt-master + converting of the locks (see below) > rt/rt - some rt git scripts > rt/convert-scripts - the scripts to convert spinlocks (see below) > rt/mainline - clean ups for mainline that we need to push forward > rt/not-for-mainline - rt only patches that we never want to push > to mainline > rt/fs - filesystem changes for rt > rt/ftrace - ftrace updates for rt > rt/java - IBM patches for java > rt/kmap > rt/lockdep > rt/pagecache > rt/percpu - this may turn into rt/mm > rt/rt-locks - the new lock API (see below) > rt/sched > rt/tasklet > rt/threadirqs - full soft and hard irq threading > rt/timer > rt/workqueue - priority queues > > We may add more rt/* branches. Most of those are self explanatory. > > The new lock API. The old -rt patch used macro magic to convert > spin_locks into mutexes depending on which type they were. A spinlock that > was declared as spinlock_t would convert into a mutex when PREEMPT_RT was > configured, where as a spinlock that was declared as raw_spinlock_t would > stay as a spinlock. > > For example: > > spinlock_t what_am_i; > raw_spinlock_t spinner; > > spin_lock(&what_am_i); > spin_lock(&spinner); > > The 'what_am_i' would turn into a mutex when PREEMPT_RT was configured and > would be a spinlock when it was not. 'spinner' would always stay as a > spinlock. The way this was done was with a builtin gcc option to compare > the type used to determine what function to call: > > #define spin_lock(lock) \ > if (__builtin_types_compatible(typeof(spinlock_t), lock)) \ > rt_lock(lock); \ > else if (__builtin_types_compatible(typeof(raw_spinlock_t), lock)) \ > raw_spin_lock(lock); \ > else \ > __bad_func_type(); > > If you are looking at this and scratching your head saying "this is not > acceptable for mainline", we agree with you ;-) This is the old way of > doing things, which made porting -rt to mainline much easier than > converting all locks to a new API. But the time has come to do just that. > > The new locks > ------------- > > The old way is not acceptable because a developer can not know when seeing > a 'spin_lock(x)' and knowing if it will stay a spinlock or not on > PREEMPT_RT. The developer would need to go search for x and see what type > it is. Then they still can not know if someone might change the type of > x. This is just ripe for bugs. > > The new RT has added a new lock API that will be a mutex when > PREEMPT_RT is configured and a spinlock when it is not. The type is called > 'lock_t' and introduces a new API acquire_lock() and release_lock(). This > also has all the irq variants that spin_locks have (acquire_lock_irqsave, > acquire_lock_irq, etc). > > lock_t lock; > > acquire_lock_irqsave(&lock, flags); > > Although it has 'irqsave' when PREEMPT_RT is defined, it will not disable > interrupts. This is fine, because with PREEMPT_RT, interrupts are threads, > and we do not need to worry about being preempted by an interrupt and have > that interrupt taking the same lock cause a deadlock. But now, the > developer knows that this is a special lock, and that the lock is not a > spinlock all the time. > > Note, you can not do: > > spin_lock(&spinner); > acquire_lock(&lock); > > This would be the same as doing: > > spin_lock(&spinner); > mutex_lock(&mutex); > > > Converting the new locks > ------------------------ > > In the git tree, there is a couple of scripts in rt/convert-scripts branch > that will convert all spinlocks into the lock_t. Then there are scripts to > convert the necessary spinlocks back to spinlock. All rt/* branches > should not need to define the type lock_t except for rt/rt-locks. > > This git repo uses similar scripts that tip uses. The rt-master branch is > a merge of all rt/* branches (except rt/rt). This may define PREEMPT_RT > but no lock is made into 'lock_t' type yet. > > The master branch is a copy of the rt-branch with the scripts to do the > lock conversion run on the tree. In other words, the master branch will > be the new -rt patch. > > Note, the current state of this git tree is still very much broken. We are > rewriting a lot of code to pull this forward to 2.6.28. Unfortunately, > this means that we are skipping 2.6.27 altogether. I will be making > another announcement when this is ready for prime time. Some of the > branches have not been updated with the changes either. > > -- Steve > Hi Steve. That's a good news. But after converting these spinlocks into lock_t, how will you synchronize with the mainline on each release? You will have a huge amount of conflicts at every merges... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/