Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!isdnet!newsfeed.wirehub.nl!news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
From: Rusty Russell <ru...@rustcorp.com.au>
To: torva...@transmeta.com
cc: linux-ker...@vger.kernel.org
Subject: [PATCH] 2.5.1-pre11 Read-Copy-Update Patch
Original-Date: Fri, 14 Dec 2001 22:27:14 +1100
Original-Message-Id: <E16EqUk-0002OG-00@wagner.rustcorp.com.au>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Fri, 14 Dec 2001 12:27:56 GMT
Message-ID: <fa.j34o9fv.e66ipg@ifi.uio.no>
Lines: 566
Hi Linus,
The hotplug CPU patch needs read-copy-update, otherwise
everyone has to lock around references to smp_num_cpus. By waiting
until everyone has scheduled, we cleanly implement two-stage CPU
removal.
Now, this patch is (obviously) currently a NOOP on UP: with
preemption on UP this would change. Are you intending to implement
preemption in 2.5, and if so, for UP or SMP?
My module loader replacement also uses RCU, to ensure noone is
still inside the module. Otherwise we continue down the current path,
and force every registration interface in the kernel to lock on entry,
unlock on exit. (If you want this, it's then a fairly short hop to a
microkernel).
I'd love to know if I should implement RCU-with-preemption on
UP, abandon the RCU approach, or send my patches as is.
Thanks,
Rusty.
URLs:
Hotplug CPU:
http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Hotcpu/hotcpu.patch.bz2
New module loader:
http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Module/module.patch.bz2
Overview:
http://www.kernel.org/pub/linux/kernel/people/rusty
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Patch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|