Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!feed.textport.net!newsfeed.media.kyoto-u.ac.jp!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Mon, 10 Sep 2001 17:54:17 +0200
From: Andrea Arcangeli <and...@suse.de>
To: linux-ker...@vger.kernel.org
Subject: 2.4.10pre7aa1
Original-Message-ID: <20010910175416.A714@athlon.random>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Mon, 10 Sep 2001 15:55:22 GMT
Message-ID: <fa.g8d2o8v.1igkgq4@ifi.uio.no>
Lines: 90
Only in 2.4.10pre4aa1: 00_ia32-bootmem-corruption-1
Only in 2.4.10pre4aa1: 00_slab-lists-1
Only in 2.4.10pre4aa1: 00_softirq-irq-1
Only in 2.4.10pre4aa1: 00_x86-systable-1
Merged in mainline.
Only in 2.4.10pre7aa1: 00_invalidate_device-shrink-dcache-1
Collect away the unused dcache before doing the same with the icache.
Only in 2.4.10pre4aa1: 00_lvm-0.9.1_beta7-6.bz2
Only in 2.4.10pre4aa1: 00_lvm-0.9.1_beta7-6_min-1
Only in 2.4.10pre4aa1: 00_lvm-0.9.1_beta7-6_rwsem-fast-path-2
Only in 2.4.10pre7aa1: 00_lvm-1.0.1-rc2-1.bz2
Upgrade to latest's lvm kernel side.
Only in 2.4.10pre7aa1: 00_module-gfp-1
Try to allocate modules in the direct mapping rather than vmalloc
to reduce the tlb misses. (from Andi)
Only in 2.4.10pre4aa1: 00_o_direct-15
Only in 2.4.10pre7aa1: 00_o_direct-16
Rediffed.
Only in 2.4.10pre4aa1: 00_paride-max_sectors-1
Only in 2.4.10pre7aa1: 00_paride-max_sectors-2
Rediffed (also noticed the gendisk list changes deleted too much stuff
here so resurrected it).
Only in 2.4.10pre7aa1: 00_rcu-1
wait_for_rcu and call_rcu implementation (from IBM). I did some
modifications with respect to the original version from IBM.
In particular I dropped the vmalloc_rcu/kmalloc_rcu, the
rcu_head must always be allocated in the data structures, it has
to be a field of a class, rather than hiding it in the allocation
and playing dirty and risky with casts on a bigger allocation.
Only in 2.4.10pre7aa1: 00_reschedule_idle-cpus_allowed-1
Reschedule_idle must be recalled during a wakeup even if the task
cannot be scheduled in the current cpu.
Only in 2.4.10pre7aa1: 00_signal-wakeup-1
Don't waste time waking up an interruptible sleeping task twice.
Only in 2.4.10pre7aa1: 00_vmalloc-flushes-1
Drop the cache flushes for the virtually indexed caches and the
tlb flushes in vmalloc path (we need that only in vfree, in
vmalloc the virtual address space that we're going to map-in is
guaranteed to be unmapped so there cannot be any cache about it).
Only in 2.4.10pre4aa1: 10_prefetch-4
Only in 2.4.10pre7aa1: 10_prefetch-5
Part of prefetch in mainline, rediffed the architectural parts.
Only in 2.4.10pre4aa1: 40_blkdev-pagecache-15
Only in 2.4.10pre7aa1: 40_blkdev-pagecache-16
Rediffed (still use rd_inode in rd.c, since it's more handy).
Only in 2.4.10pre4aa1: 50_uml-patch-2.4.9-3.bz2
Only in 2.4.10pre7aa1: 50_uml-patch-2.4.9-4.bz2
Picked last update from sourceforge.
Only in 2.4.10pre7aa1: 60_tux-2.4.9-ac10-G5
Only in 2.4.10pre4aa1: 60_tux-2.4.9-ac5-C0-4
Picked last update from www.redhat.com/~mingo/ .
URL:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.10pre7aa1/
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.10pre7aa1.bz2
Andrea
-
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/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!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>
Original-Date: Mon, 10 Sep 2001 19:41:58 +0200
Original-Message-Id: <200109101741.f8AHfwx17136@ns.caldera.de>
From: h...@caldera.de (Christoph Hellwig)
To: and...@suse.de (Andrea Arcangeli)
Cc: linux-ker...@vger.kernel.org
Subject: Re: 2.4.10pre7aa1
X-Newsgroups: caldera.lists.linux.kernel
In-Reply-To: <20010910175416.A714@athlon.random>
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.2 (i686))
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Mon, 10 Sep 2001 17:44:13 GMT
Message-ID: <fa.efr54pv.1sik083@ifi.uio.no>
References: <fa.g8d2o8v.1igkgq4@ifi.uio.no>
Lines: 72
In article <20010910175416.A...@athlon.random> you wrote:
> Only in 2.4.10pre4aa1: 00_paride-max_sectors-1
> Only in 2.4.10pre7aa1: 00_paride-max_sectors-2
>
> Rediffed (also noticed the gendisk list changes deleted too much stuff
> here so resurrected it).
Do you plan to submit the max_sectors changes to Linus & Alan?
Otherwise I will do as they seem to be needed for reliable operation.
> Only in 2.4.10pre7aa1: 00_rcu-1
>
> wait_for_rcu and call_rcu implementation (from IBM). I did some
> modifications with respect to the original version from IBM.
> In particular I dropped the vmalloc_rcu/kmalloc_rcu, the
> rcu_head must always be allocated in the data structures, it has
> to be a field of a class, rather than hiding it in the allocation
> and playing dirty and risky with casts on a bigger allocation.
Do we really need yet-another per-CPU thread for this? I'd prefer to have
the context thread per-CPU instead (like in Ben's asynchio patch) and do
this as well.
BTW, do you plan to merge patches that actually _use_ this into your tree?
> Only in 2.4.10pre4aa1: 10_prefetch-4
> Only in 2.4.10pre7aa1: 10_prefetch-5
>
> Part of prefetch in mainline, rediffed the architectural parts.
In my tree I also have an ia64 prefetch patch (I think it's from redhat,
not sure though), it's appended if you want to take it.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
--- linux/include/asm-ia64/processor.h.org Thu Jun 28 12:43:20 2001
+++ linux/include/asm-ia64/processor.h Thu Jun 28 12:48:28 2001
@@ -958,6 +958,25 @@
return result;
}
+
+#define ARCH_HAS_PREFETCH
+#define ARCH_HAS_PREFETCHW
+#define ARCH_HAS_SPINLOCK_PREFETCH
+#define PREFETCH_STRIDE 256
+
+extern inline void prefetch(const void *x)
+{
+ __asm__ __volatile__ ("lfetch [%0]" : : "r"(x));
+}
+
+extern inline void prefetchw(const void *x)
+{
+ __asm__ __volatile__ ("lfetch.excl [%0]" : : "r"(x));
+}
+
+#define spin_lock_prefetch(x) prefetchw(x)
+
+
#endif /* !__ASSEMBLY__ */
#endif /* _ASM_IA64_PROCESSOR_H */
-
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/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!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>
Original-Date: Mon, 10 Sep 2001 20:03:44 +0200
From: Andrea Arcangeli <and...@suse.de>
To: Christoph Hellwig <h...@caldera.de>
Cc: linux-ker...@vger.kernel.org, Linus Torvalds <torva...@transmeta.com>
Subject: Re: 2.4.10pre7aa1
Original-Message-ID: <20010910200344.C714@athlon.random>
Original-References: <20010910175416.A...@athlon.random> <200109101741.f8AHfwx17...@ns.caldera.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200109101741.f8AHfwx17136@ns.caldera.de>; from hch@caldera.de on Mon, Sep 10, 2001 at 07:41:58PM +0200
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Mon, 10 Sep 2001 18:05:22 GMT
Message-ID: <fa.gacgn0v.1hguhi1@ifi.uio.no>
References: <fa.efr54pv.1sik083@ifi.uio.no>
Lines: 172
On Mon, Sep 10, 2001 at 07:41:58PM +0200, Christoph Hellwig wrote:
> In article <20010910175416.A...@athlon.random> you wrote:
> > Only in 2.4.10pre4aa1: 00_paride-max_sectors-1
> > Only in 2.4.10pre7aa1: 00_paride-max_sectors-2
> >
> > Rediffed (also noticed the gendisk list changes deleted too much stuff
> > here so resurrected it).
>
> Do you plan to submit the max_sectors changes to Linus & Alan?
> Otherwise I will do as they seem to be needed for reliable operation.
agreed, Linus, here it is ready for merging into mainline:
diff -urN 2.4.10pre6/drivers/block/paride/pd.c paride/drivers/block/paride/pd.c
--- 2.4.10pre6/drivers/block/paride/pd.c Sun Sep 9 06:04:54 2001
+++ paride/drivers/block/paride/pd.c Mon Sep 10 03:58:48 2001
@@ -287,6 +287,7 @@
static struct hd_struct pd_hd[PD_DEVS];
static int pd_sizes[PD_DEVS];
static int pd_blocksizes[PD_DEVS];
+static int pd_maxsectors[PD_DEVS];
#define PD_NAMELEN 8
@@ -385,56 +386,6 @@
}
}
-static inline int pd_new_segment(request_queue_t *q, struct request *req, int max_segments)
-{
- if (max_segments > cluster)
- max_segments = cluster;
-
- if (req->nr_segments < max_segments) {
- req->nr_segments++;
- return 1;
- }
- return 0;
-}
-
-static int pd_back_merge_fn(request_queue_t *q, struct request *req,
- struct buffer_head *bh, int max_segments)
-{
- if (req->bhtail->b_data + req->bhtail->b_size == bh->b_data)
- return 1;
- return pd_new_segment(q, req, max_segments);
-}
-
-static int pd_front_merge_fn(request_queue_t *q, struct request *req,
- struct buffer_head *bh, int max_segments)
-{
- if (bh->b_data + bh->b_size == req->bh->b_data)
- return 1;
- return pd_new_segment(q, req, max_segments);
-}
-
-static int pd_merge_requests_fn(request_queue_t *q, struct request *req,
- struct request *next, int max_segments)
-{
- int total_segments = req->nr_segments + next->nr_segments;
- int same_segment;
-
- if (max_segments > cluster)
- max_segments = cluster;
-
- same_segment = 0;
- if (req->bhtail->b_data + req->bhtail->b_size == next->bh->b_data) {
- total_segments--;
- same_segment = 1;
- }
-
- if (total_segments > max_segments)
- return 0;
-
- req->nr_segments = total_segments;
- return 1;
-}
-
int pd_init (void)
{ int i;
@@ -448,9 +399,6 @@
}
q = BLK_DEFAULT_QUEUE(MAJOR_NR);
blk_init_queue(q, DEVICE_REQUEST);
- q->back_merge_fn = pd_back_merge_fn;
- q->front_merge_fn = pd_front_merge_fn;
- q->merge_requests_fn = pd_merge_requests_fn;
read_ahead[MAJOR_NR] = 8; /* 8 sector (4kB) read ahead */
pd_gendisk.major = major;
@@ -460,6 +408,9 @@
for(i=0;i<PD_DEVS;i++) pd_blocksizes[i] = 1024;
blksize_size[MAJOR_NR] = pd_blocksizes;
+ for(i=0;i<PD_DEVS;i++) pd_maxsectors[i] = cluster;
+ max_sectors[MAJOR_NR] = pd_maxsectors;
+
printk("%s: %s version %s, major %d, cluster %d, nice %d\n",
name,name,PD_VERSION,major,cluster,nice);
pd_init_units();
@@ -642,6 +593,11 @@
devfs_unregister_blkdev(MAJOR_NR,name);
del_gendisk(&pd_gendisk);
+
+ for (unit=0;unit<PD_UNITS;unit++)
+ if (PD.present) pi_release(PI);
+
+ max_sectors[MAJOR_NR] = NULL;
}
#endif
> > Only in 2.4.10pre7aa1: 00_rcu-1
> >
> > wait_for_rcu and call_rcu implementation (from IBM). I did some
> > modifications with respect to the original version from IBM.
> > In particular I dropped the vmalloc_rcu/kmalloc_rcu, the
> > rcu_head must always be allocated in the data structures, it has
> > to be a field of a class, rather than hiding it in the allocation
> > and playing dirty and risky with casts on a bigger allocation.
>
> Do we really need yet-another per-CPU thread for this? I'd prefer to have
> the context thread per-CPU instead (like in Ben's asynchio patch) and do
> this as well.
The first desing solution I proposed to Paul and Dipankar was just to
use ksoftirqd for that (in short set need_resched and wait it to be
cleared), it worked out nicely and it was a sensible improvement with
respect to their previous patches. (also it was reliable, we cannot
afford allocations in the wait_for_rcu path to avoid having to introduce
fail paths) it was also a noop to the ksoftirqd paths.
However they remarked ksoftirqd wasn't a RT thread so under very high
load it could introduce an higher latency to the wait_for_rcu calls.
keventd as well isn't a RT task and furthmore currently the
schedule_task as the property that only one task in the keventd queue
will be run at once (but I guess for the latter issue we can probably
ignore it since it's better not to rely on it).
So the obvious next step was to waste another 8k per cpu and to get the
best runtime behaviour and also very clean and self contained code. I
think that's rasonable.
So in short if you really are in pain for 8k per cpu to get the best
runtime behaviour and cleaner code I'd at least suggest to use the
ksoftirqd way that should be the next best step.
> BTW, do you plan to merge patches that actually _use_ this into your tree?
Long term of course, but with my further changes before the inclusion
the plain current patches shouldn't apply any longer, I'd like if the
developers of the current rcu fd patches could check my changes and
adapt them (if they agree with my changes of course ;).
> > Only in 2.4.10pre4aa1: 10_prefetch-4
> > Only in 2.4.10pre7aa1: 10_prefetch-5
> >
> > Part of prefetch in mainline, rediffed the architectural parts.
>
> In my tree I also have an ia64 prefetch patch (I think it's from redhat,
> not sure though), it's appended if you want to take it.
thanks, applied.
Andrea
-
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/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!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>
Original-Date: Mon, 10 Sep 2001 20:52:50 +0200
From: Christoph Hellwig <h...@caldera.de>
To: Andrea Arcangeli <and...@suse.de>
Cc: linux-ker...@vger.kernel.org
Subject: Re: 2.4.10pre7aa1
Original-Message-ID: <20010910205250.B22889@caldera.de>
Mail-Followup-To: Christoph Hellwig <h...@caldera.de>,
Andrea Arcangeli <and...@suse.de>, linux-ker...@vger.kernel.org
Original-References: <20010910175416.A...@athlon.random> <200109101741.f8AHfwx17...@ns.caldera.de> <20010910200344.C...@athlon.random>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010910200344.C714@athlon.random>; from andrea@suse.de on Mon, Sep 10, 2001 at 08:03:44PM +0200
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Mon, 10 Sep 2001 18:54:30 GMT
Message-ID: <fa.dtjnilv.127sgbd@ifi.uio.no>
References: <fa.gacgn0v.1hguhi1@ifi.uio.no>
Lines: 37
On Mon, Sep 10, 2001 at 08:03:44PM +0200, Andrea Arcangeli wrote:
> > Do we really need yet-another per-CPU thread for this? I'd prefer to have
> > the context thread per-CPU instead (like in Ben's asynchio patch) and do
> > this as well.
>
> The first desing solution I proposed to Paul and Dipankar was just to
> use ksoftirqd for that (in short set need_resched and wait it to be
> cleared), it worked out nicely and it was a sensible improvement with
> respect to their previous patches. (also it was reliable, we cannot
> afford allocations in the wait_for_rcu path to avoid having to introduce
> fail paths) it was also a noop to the ksoftirqd paths.
>
> However they remarked ksoftirqd wasn't a RT thread so under very high
> load it could introduce an higher latency to the wait_for_rcu calls.
Hmm, I don't see why latency is important for rcu - we only want to
free datastructures.. (mm load?).
On the other hands they are the experts on RCU, not I so I'll believe them.
> So in short if you really are in pain for 8k per cpu to get the best
> runtime behaviour and cleaner code I'd at least suggest to use the
> ksoftirqd way that should be the next best step.
My problem with this appropech is just that we use kernel threads for
more and more stuff - always creating new ones. I think at some point
they will sum up badly.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
-
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/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!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>
Original-Date: Tue, 11 Sep 2001 14:21:58 +0530
From: Dipankar Sarma <dipan...@in.ibm.com>
To: h...@caldera.de
Cc: linux-ker...@vger.kernel.org, Paul Mckenney <paul.mcken...@us.ibm.com>,
Andrea Arcangeli <and...@suse.de>
Subject: Re: 2.4.10pre7aa1
Original-Message-ID: <20010911142158.A1537@in.ibm.com>
Reply-To: dipan...@in.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 11 Sep 2001 08:49:31 GMT
Message-ID: <fa.dpudcmv.p5a4g0@ifi.uio.no>
Lines: 53
Hi Christoph,
In article <20010910205250.B22...@caldera.de> you wrote:
> Hmm, I don't see why latency is important for rcu - we only want to
> free datastructures.. (mm load?).
While it is not important for RCU to do the updates quickly, it is
still necessary that updates are not completely starved out by
high-priority tasks. So, the idea behind using high-priority
krcuds is to ensure that they don't get starved thereby delaying
updates for unreasonably long periods of time which could lead
to memory pressure or other performance problems depending on
how RCU is being used.
> On the other hands they are the experts on RCU, not I so I'll believe them.
>> So in short if you really are in pain for 8k per cpu to get the best
>> runtime behaviour and cleaner code I'd at least suggest to use the
>> ksoftirqd way that should be the next best step.
> My problem with this appropech is just that we use kernel threads for
> more and more stuff - always creating new ones. I think at some point
> they will sum up badly.
> Christoph
I agree that it is not always a good idea to use kernel threads for
everything, but in this case this seems to be the safest and
most reasonable option.
FYI, there are a couple of other implementations, but they all affect
code in fast paths even if there is no RCU going on in the system.
One of them is from Rusty that keeps track of CPUs going through
quiescent state from the scheduler context and also executes the
callbacks from the scheduler context. The other patch is based
on our old DYNIX/ptx implementation - it uses one per-cpu context
switch counter to detect quiescent state and checks for completion
of RCU in local timer interrupt handler. Once all the CPUs go
through a quiescent state, the callbacks are processed using
a tasklet.
Thanks
Dipankar
--
Dipankar Sarma <dipan...@in.ibm.com> Project: http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
-
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/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!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>
Original-Date: Tue, 11 Sep 2001 13:04:30 +0200
From: Andrea Arcangeli <and...@suse.de>
To: Dipankar Sarma <dipan...@in.ibm.com>
Cc: h...@caldera.de, linux-ker...@vger.kernel.org,
Paul Mckenney <paul.mcken...@us.ibm.com>
Subject: Re: 2.4.10pre7aa1
Original-Message-ID: <20010911130430.L715@athlon.random>
Original-References: <20010911142158.A1...@in.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20010911142158.A1537@in.ibm.com>; from dipankar@in.ibm.com on Tue, Sep 11, 2001 at 02:21:58PM +0530
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 11 Sep 2001 11:10:25 GMT
Message-ID: <fa.g9cen8v.1jgghq8@ifi.uio.no>
References: <fa.dpudcmv.p5a4g0@ifi.uio.no>
Lines: 274
On Tue, Sep 11, 2001 at 02:21:58PM +0530, Dipankar Sarma wrote:
> Hi Christoph,
>
> In article <20010910205250.B22...@caldera.de> you wrote:
>
> > Hmm, I don't see why latency is important for rcu - we only want to
> > free datastructures.. (mm load?).
>
> While it is not important for RCU to do the updates quickly, it is
> still necessary that updates are not completely starved out by
> high-priority tasks. So, the idea behind using high-priority
> krcuds is to ensure that they don't get starved thereby delaying
> updates for unreasonably long periods of time which could lead
> to memory pressure or other performance problems depending on
> how RCU is being used.
good point.
> I agree that it is not always a good idea to use kernel threads for
> everything, but in this case this seems to be the safest and
> most reasonable option.
pretty much agreed.
BTW, I fixed a few more issues in the rcu patch (grep for
down_interruptible for instance), here an updated patch (will be
included in 2.4.10pre8aa1 [or later -aa]) with the name of rcu-2.
diff -urN 2.4.10pre8/include/linux/rcupdate.h rcu/include/linux/rcupdate.h
--- 2.4.10pre8/include/linux/rcupdate.h Thu Jan 1 01:00:00 1970
+++ rcu/include/linux/rcupdate.h Tue Sep 11 06:14:17 2001
@@ -0,0 +1,48 @@
+/*
+ * Read-Copy Update mechanism for Linux
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * For detailed explanation of Read-Copy Update mechanism see -
+ * http://lse.sourceforge.net/locking/rcupdate.html
+ *
+ */
+
+#ifndef _LINUX_RCUPDATE_H
+#define _LINUX_RCUPDATE_H
+
+#include <linux/malloc.h>
+#include <linux/vmalloc.h>
+#include <linux/cache.h>
+#include <asm/semaphore.h>
+
+struct rcu_data {
+ struct task_struct *krcud_task;
+ struct semaphore krcud_sema;
+} ____cacheline_aligned_in_smp;
+
+#define krcud_task(cpu) rcu_data[(cpu)].krcud_task
+#define krcud_sema(cpu) rcu_data[(cpu)].krcud_sema
+
+struct rcu_head
+{
+ struct list_head list;
+ void (*func)(void * arg);
+ void * arg;
+};
+
+extern void call_rcu(struct rcu_head * head, void (*func)(void * arg), void * arg);
+
+#endif
diff -urN 2.4.10pre8/kernel/Makefile rcu/kernel/Makefile
--- 2.4.10pre8/kernel/Makefile Tue Sep 11 04:10:03 2001
+++ rcu/kernel/Makefile Tue Sep 11 06:14:17 2001
@@ -9,12 +9,12 @@
O_TARGET := kernel.o
-export-objs = signal.o sys.o kmod.o context.o ksyms.o pm.o exec_domain.o
+export-objs = signal.o sys.o kmod.o context.o ksyms.o pm.o exec_domain.o rcupdate.o
obj-y = sched.o dma.o fork.o exec_domain.o panic.o printk.o \
module.o exit.o itimer.o info.o time.o softirq.o resource.o \
sysctl.o acct.o capability.o ptrace.o timer.o user.o \
- signal.o sys.o kmod.o context.o
+ signal.o sys.o kmod.o context.o rcupdate.o
obj-$(CONFIG_UID16) += uid16.o
obj-$(CONFIG_MODULES) += ksyms.o
diff -urN 2.4.10pre8/kernel/rcupdate.c rcu/kernel/rcupdate.c
--- 2.4.10pre8/kernel/rcupdate.c Thu Jan 1 01:00:00 1970
+++ rcu/kernel/rcupdate.c Tue Sep 11 06:16:39 2001
@@ -0,0 +1,165 @@
+/*
+ * Read-Copy Update mechanism for Linux
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * For detailed explanation of Read-Copy Update mechanism see -
+ * http://lse.sourceforge.net/locking/rcupdate.html
+ *
+ */
+
+#include <linux/rcupdate.h>
+#include <linux/spinlock.h>
+#include <linux/tqueue.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/init.h>
+#include <linux/tqueue.h>
+
+asmlinkage long sys_sched_get_priority_max(int policy);
+
+static spinlock_t rcu_lock = SPIN_LOCK_UNLOCKED;
+static struct list_head rcu_wait_list;
+static struct tq_struct rcu_task;
+static struct semaphore rcu_sema;
+static struct rcu_data rcu_data[NR_CPUS];
+
+/*
+ * Wait for all the CPUs to go through a quiescent state. It assumes
+ * that current CPU doesn't have any reference to RCU protected
+ * data and thus has already undergone a quiescent state since update.
+ */
+static void wait_for_rcu(void)
+{
+ int cpu;
+ int count;
+
+ for (cpu = 0; cpu < smp_num_cpus; cpu++) {
+ if (cpu == smp_processor_id())
+ continue;
+ up(&krcud_sema(cpu));
+ }
+ count = 0;
+ while (count++ < smp_num_cpus - 1)
+ down(&rcu_sema);
+}
+
+/*
+ * Process a batch of RCU callbacks (the batch can be empty).
+ * There can be only one batch processed at any point of time.
+ */
+static void process_pending_rcus(void *arg)
+{
+ LIST_HEAD(rcu_current_list);
+ struct list_head * entry;
+
+ spin_lock_irq(&rcu_lock);
+ list_splice(&rcu_wait_list, rcu_current_list.prev);
+ INIT_LIST_HEAD(&rcu_wait_list);
+ spin_unlock_irq(&rcu_lock);
+
+ wait_for_rcu();
+
+ while ((entry = rcu_current_list.prev) != &rcu_current_list) {
+ struct rcu_head * head;
+
+ list_del(entry);
+ head = list_entry(entry, struct rcu_head, list);
+ head->func(head->arg);
+ }
+}
+
+/*
+ * Register a RCU callback to be invoked after all CPUs have
+ * gone through a quiescent state.
+ */
+void call_rcu(struct rcu_head * head, void (*func)(void * arg), void * arg)
+{
+ unsigned long flags;
+ int start = 0;
+
+ head->func = func;
+ head->arg = arg;
+
+ spin_lock_irqsave(&rcu_lock, flags);
+ if (list_empty(&rcu_wait_list))
+ start = 1;
+ list_add(&head->list, &rcu_wait_list);
+ spin_unlock_irqrestore(&rcu_lock, flags);
+
+ if (start)
+ schedule_task(&rcu_task);
+}
+
+/*
+ * Per-CPU RCU dameon. It runs at an absurdly high priority so
+ * that it is not starved out by the scheduler thereby holding
+ * up RC updates.
+ */
+static int krcud(void * __bind_cpu)
+{
+ int bind_cpu = *(int *) __bind_cpu;
+ int cpu = cpu_logical_map(bind_cpu);
+
+ daemonize();
+ current->policy = SCHED_FIFO;
+ current->rt_priority = 1001 + sys_sched_get_priority_max(SCHED_FIFO);
+
+ sigfillset(¤t->blocked);
+
+ /* Migrate to the right CPU */
+ current->cpus_allowed = 1UL << cpu;
+ while (smp_processor_id() != cpu)
+ schedule();
+
+ sprintf(current->comm, "krcud_CPU%d", bind_cpu);
+ sema_init(&krcud_sema(cpu), 0);
+
+ krcud_task(cpu) = current;
+
+ for (;;) {
+ while (down_interruptible(&krcud_sema(cpu)));
+ up(&rcu_sema);
+ }
+}
+
+static void spawn_krcud(void)
+{
+ int cpu;
+
+ for (cpu = 0; cpu < smp_num_cpus; cpu++) {
+ if (kernel_thread(krcud, (void *) &cpu,
+ CLONE_FS | CLONE_FILES | CLONE_SIGNAL) < 0)
+ printk("spawn_krcud() failed for cpu %d\n", cpu);
+ else {
+ while (!krcud_task(cpu_logical_map(cpu))) {
+ current->policy |= SCHED_YIELD;
+ schedule();
+ }
+ }
+ }
+}
+
+static __init int rcu_init(void)
+{
+ sema_init(&rcu_sema, 0);
+ rcu_task.routine = process_pending_rcus;
+ spawn_krcud();
+ return 0;
+}
+
+__initcall(rcu_init);
+
+EXPORT_SYMBOL(call_rcu);
Andrea
-
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/
Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newsfeed.icl.net!npeer.kpnqwest.net!Norway.EU.net!uninett.no!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Subject: Re: 2.4.10pre7aa1
To: and...@suse.de (Andrea Arcangeli)
Original-Date: Tue, 11 Sep 2001 13:40:37 +0100 (BST)
Cc: dipan...@in.ibm.com (Dipankar Sarma), h...@caldera.de,
linux-ker...@vger.kernel.org, paul.mcken...@us.ibm.com (Paul Mckenney)
In-Reply-To: <20010911130430.L715@athlon.random> from "Andrea Arcangeli" at Sep 11, 2001 01:04:30 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Original-Message-Id: <E15gmqD-0002YK-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 11 Sep 2001 12:39:07 GMT
Message-ID: <fa.gv3as0v.1u7miga@ifi.uio.no>
References: <fa.g9cen8v.1jgghq8@ifi.uio.no>
Lines: 16
> BTW, I fixed a few more issues in the rcu patch (grep for
> down_interruptible for instance), here an updated patch (will be
> included in 2.4.10pre8aa1 [or later -aa]) with the name of rcu-2.
I've been made aware of one other isue with the RCU patch
US Patent #05442758
In the absence of an actual real signed header paper patent use grant for GPL
usage from the Sequent folks that seems to be rather hard to fix.
Alan
-
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/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!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>
Original-Date: Tue, 11 Sep 2001 18:35:34 +0530
From: Dipankar Sarma <dipan...@in.ibm.com>
To: a...@lxorguk.ukuu.org.uk
Cc: Paul Mckenney <paul.mcken...@us.ibm.com>,
Andrea Arcangeli <and...@suse.de>, linux-ker...@vger.kernel.org
Subject: Re: 2.4.10pre7aa1
Original-Message-ID: <20010911183534.A2340@in.ibm.com>
Reply-To: dipan...@in.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 11 Sep 2001 13:02:53 GMT
Message-ID: <fa.dpe9d6v.rl6503@ifi.uio.no>
Lines: 30
In article <E15gmqD-0002YK...@the-village.bc.nu> you wrote:
>> BTW, I fixed a few more issues in the rcu patch (grep for
>> down_interruptible for instance), here an updated patch (will be
>> included in 2.4.10pre8aa1 [or later -aa]) with the name of rcu-2.
> I've been made aware of one other isue with the RCU patch
> US Patent #05442758
> In the absence of an actual real signed header paper patent use grant for GPL
> usage from the Sequent folks that seems to be rather hard to fix.
> Alan
Hi Alan,
IBM bought us a couple of years ago and linux RCU is an IBM approved
project. I am not sure I understand what exactly is needed for patent use
grant for GPL, but whatever it is, I see absolutely no problem getting it done.
I would appreciate if you let me know what is needed for GPL.
Thanks
Dipankar
--
Dipankar Sarma <dipan...@in.ibm.com> Project: http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
-
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/
Path: archiver1.google.com!news2.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.media.kyoto-u.ac.jp!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Tue, 11 Sep 2001 15:49:19 +0200
From: Andrea Arcangeli <and...@suse.de>
To: Alan Cox <a...@lxorguk.ukuu.org.uk>
Cc: Dipankar Sarma <dipan...@in.ibm.com>, h...@caldera.de,
linux-ker...@vger.kernel.org, Paul Mckenney <paul.mcken...@us.ibm.com>
Subject: Re: 2.4.10pre7aa1
Original-Message-ID: <20010911154919.Z715@athlon.random>
Original-References: <20010911130430.L...@athlon.random> <E15gmqD-0002YK...@the-village.bc.nu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E15gmqD-0002YK-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Tue, Sep 11, 2001 at 01:40:37PM +0100
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 11 Sep 2001 13:52:51 GMT
Message-ID: <fa.g8d4o9v.1igegqj@ifi.uio.no>
References: <fa.gv3as0v.1u7miga@ifi.uio.no>
Lines: 22
On Tue, Sep 11, 2001 at 01:40:37PM +0100, Alan Cox wrote:
> > BTW, I fixed a few more issues in the rcu patch (grep for
> > down_interruptible for instance), here an updated patch (will be
> > included in 2.4.10pre8aa1 [or later -aa]) with the name of rcu-2.
>
> I've been made aware of one other isue with the RCU patch
> US Patent #05442758
>
> In the absence of an actual real signed header paper patent use grant for GPL
> usage from the Sequent folks that seems to be rather hard to fix.
many thanks for the info. Since I live in Italy I should be safe to use
it and to contribute the developement until Sequent/IBM fixes the legal
problem. As far I can tell it's quite obviously just a theorical problem
but it was very worth noticing.
Andrea
-
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/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!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>
Original-Date: Tue, 11 Sep 2001 15:56:52 +0200
From: Andrea Arcangeli <and...@suse.de>
To: Dipankar Sarma <dipan...@in.ibm.com>
Cc: a...@lxorguk.ukuu.org.uk, Paul Mckenney <paul.mcken...@us.ibm.com>,
linux-ker...@vger.kernel.org
Subject: Re: 2.4.10pre7aa1
Original-Message-ID: <20010911155652.A715@athlon.random>
Original-References: <20010911183534.A2...@in.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20010911183534.A2340@in.ibm.com>; from dipankar@in.ibm.com on Tue, Sep 11, 2001 at 06:35:34PM +0530
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 11 Sep 2001 13:57:32 GMT
Message-ID: <fa.gacmogv.1ggogi7@ifi.uio.no>
References: <fa.dpe9d6v.rl6503@ifi.uio.no>
Lines: 39
On Tue, Sep 11, 2001 at 06:35:34PM +0530, Dipankar Sarma wrote:
> In article <E15gmqD-0002YK...@the-village.bc.nu> you wrote:
> >> BTW, I fixed a few more issues in the rcu patch (grep for
> >> down_interruptible for instance), here an updated patch (will be
> >> included in 2.4.10pre8aa1 [or later -aa]) with the name of rcu-2.
>
> > I've been made aware of one other isue with the RCU patch
> > US Patent #05442758
>
> > In the absence of an actual real signed header paper patent use grant for GPL
> > usage from the Sequent folks that seems to be rather hard to fix.
>
> > Alan
>
> Hi Alan,
>
> IBM bought us a couple of years ago and linux RCU is an IBM approved
> project. I am not sure I understand what exactly is needed for patent use
> grant for GPL, but whatever it is, I see absolutely no problem getting it done.
> I would appreciate if you let me know what is needed for GPL.
Nothing is needed but without changes we would prefer not to include the
rcu patch in the kernel. AFIK (and I'm far from being an expert here) I
can upload the source protected by patent to kernel.org and everybody
but US citizens can safely run the code protected by patent without
having to pay the patent holder. So in short the problem is that it
wouldn't be nice if you could download freely the linux kernel but you
couldn't use it freely in the US without first dropping the rcu patch.
In short AFIK from your part you should just make a modification to the
patent (or whatever else legal paperwork) saying that the usage of the
rcu technology in GPL code is allowed free of charge.
Andrea
-
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/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!134.222.94.5!npeer.kpnqwest.net!Norway.EU.net!uninett.no!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Tue, 11 Sep 2001 19:57:51 +0530
From: Dipankar Sarma <dipan...@in.ibm.com>
To: Andrea Arcangeli <and...@suse.de>
Cc: a...@lxorguk.ukuu.org.uk, Paul Mckenney <paul.mcken...@us.ibm.com>,
linux-ker...@vger.kernel.org
Subject: Re: 2.4.10pre7aa1
Original-Message-ID: <20010911195751.H1667@in.ibm.com>
Reply-To: dipan...@in.ibm.com
Original-References: <20010911183534.A2...@in.ibm.com> <20010911155652.A...@athlon.random>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20010911155652.A715@athlon.random>; from andrea@suse.de on Tue, Sep 11, 2001 at 03:56:52PM +0200
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 11 Sep 2001 14:27:26 GMT
Message-ID: <fa.dpube7v.p5440f@ifi.uio.no>
References: <fa.gacmogv.1ggogi7@ifi.uio.no>
Lines: 30
On Tue, Sep 11, 2001 at 03:56:52PM +0200, Andrea Arcangeli wrote:
> Nothing is needed but without changes we would prefer not to include the
> rcu patch in the kernel. AFIK (and I'm far from being an expert here) I
> can upload the source protected by patent to kernel.org and everybody
> but US citizens can safely run the code protected by patent without
> having to pay the patent holder. So in short the problem is that it
> wouldn't be nice if you could download freely the linux kernel but you
> couldn't use it freely in the US without first dropping the rcu patch.
>
> In short AFIK from your part you should just make a modification to the
> patent (or whatever else legal paperwork) saying that the usage of the
> rcu technology in GPL code is allowed free of charge.
I don't think the patent issue is going to be a problem since the work has
long been approved at IBM, legal-wise. It is just that none of us were
aware of what is required for grant of use.
I have already started the follow up process in Beaverton and will get back to
you ASAP. Sorry about the confusion.
Thanks
Dipankar
--
Dipankar Sarma <dipan...@in.ibm.com> Project: http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
-
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/
Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!isdnet!newsgate.cistron.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>
Original-Date: Wed, 12 Sep 2001 18:24:40 +1000
From: Rusty Russell <ru...@rustcorp.com.au>
To: Andrea Arcangeli <and...@suse.de>
Cc: linux-ker...@vger.kernel.org
Subject: Re: 2.4.10pre7aa1
Original-Message-Id: <20010912182440.3975719b.rusty@rustcorp.com.au>
In-Reply-To: <20010910175416.A714@athlon.random>
Original-References: <20010910175416.A...@athlon.random>
X-Mailer: Sylpheed version 0.5.3 (GTK+ 1.2.10; powerpc-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Wed, 12 Sep 2001 08:25:58 GMT
Message-ID: <fa.les4qvv.16h8prg@ifi.uio.no>
References: <fa.g8d2o8v.1igkgq4@ifi.uio.no>
Lines: 233
On Mon, 10 Sep 2001 17:54:17 +0200
Andrea Arcangeli <and...@suse.de> wrote:
> Only in 2.4.10pre7aa1: 00_rcu-1
>
> wait_for_rcu and call_rcu implementation (from IBM). I did some
> modifications with respect to the original version from IBM.
> In particular I dropped the vmalloc_rcu/kmalloc_rcu, the
> rcu_head must always be allocated in the data structures, it has
> to be a field of a class, rather than hiding it in the allocation
> and playing dirty and risky with casts on a bigger allocation.
Hi Andrea,
Like the kernel threads approach, but AFAICT it won't work for the
case of two CPUs running wait_for_rcu at the same time (on a 4-way or above).
Please try actually *using* the RCU code before you complain about the wrappers:
you'll end up writing your own wrappers. I look forward to seeing what you come
up with (handling the case of the rcu structure in an arbitrary offset within the
structure is possible, but my solutions were all less neat).
Preferred patch below,
Rusty.
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal working-2.4.7-module/include/linux/rcupdate.h working-2.4.7-rcu/include/linux/rcupdate.h
--- working-2.4.7-module/include/linux/rcupdate.h Thu Jan 1 10:00:00 1970
+++ working-2.4.7-rcu/include/linux/rcupdate.h Wed Aug 29 10:19:13 2001
@@ -0,0 +1,58 @@
+#ifndef _LINUX_RCUPDATE_H
+#define _LINUX_RCUPDATE_H
+/* Read-Copy-Update For Linux. */
+#include <linux/malloc.h>
+#include <linux/cache.h>
+#include <linux/vmalloc.h>
+#include <asm/atomic.h>
+
+struct rcu_head
+{
+ struct rcu_head *next;
+ void (*func)(void *obj);
+};
+
+/* Count of pending requests: for optimization in schedule() */
+extern atomic_t rcu_pending;
+
+/* Queues future request. */
+void call_rcu(struct rcu_head *head, void (*func)(void *head));
+
+/* Convenience wrappers: */
+static inline void *kmalloc_rcu(size_t size, int flags)
+{
+ void *ret;
+
+ size += L1_CACHE_ALIGN(sizeof(struct rcu_head));
+ ret = kmalloc(size, flags);
+ if (!ret)
+ return NULL;
+ return ret + L1_CACHE_ALIGN(sizeof(struct rcu_head));
+}
+
+static inline void kfree_rcu(void *obj)
+{
+ call_rcu(obj - L1_CACHE_ALIGN(sizeof(struct rcu_head)),
+ (void (*)(void *))kfree);
+}
+
+static inline void *vmalloc_rcu(size_t size)
+{
+ void *ret;
+
+ size += L1_CACHE_ALIGN(sizeof(struct rcu_head));
+ ret = vmalloc(size);
+ if (!ret)
+ return NULL;
+ return ret + L1_CACHE_ALIGN(sizeof(struct rcu_head));
+}
+
+static inline void vfree_rcu(void *obj)
+{
+ call_rcu(obj - L1_CACHE_ALIGN(sizeof(struct rcu_head)),
+ (void (*)(void *))vfree);
+}
+
+/* Called by schedule() when batch reference count drops to zero. */
+void rcu_batch_done(void);
+#endif
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal working-2.4.7-module/kernel/Makefile working-2.4.7-rcu/kernel/Makefile
--- working-2.4.7-module/kernel/Makefile Sat Dec 30 09:07:24 2000
+++ working-2.4.7-rcu/kernel/Makefile Wed Aug 29 10:12:08 2001
@@ -9,12 +9,12 @@
O_TARGET := kernel.o
-export-objs = signal.o sys.o kmod.o context.o ksyms.o pm.o
+export-objs = signal.o sys.o kmod.o context.o ksyms.o pm.o rcupdate.o
obj-y = sched.o dma.o fork.o exec_domain.o panic.o printk.o \
module.o exit.o itimer.o info.o time.o softirq.o resource.o \
sysctl.o acct.o capability.o ptrace.o timer.o user.o \
- signal.o sys.o kmod.o context.o
+ signal.o sys.o kmod.o context.o rcupdate.o
obj-$(CONFIG_UID16) += uid16.o
obj-$(CONFIG_MODULES) += ksyms.o
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal working-2.4.7-module/kernel/rcupdate.c working-2.4.7-rcu/kernel/rcupdate.c
--- working-2.4.7-module/kernel/rcupdate.c Thu Jan 1 10:00:00 1970
+++ working-2.4.7-rcu/kernel/rcupdate.c Wed Aug 29 10:20:31 2001
@@ -0,0 +1,65 @@
+/* Read-Copy-Update For Linux. */
+#include <linux/rcupdate.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+
+/* Count of pending requests: for optimization in schedule() */
+atomic_t rcu_pending = ATOMIC_INIT(0);
+
+/* Two batches per CPU : one (pending) is an internal queue of waiting
+ requests, being prepended to as new requests come in. The other
+ (rcu_waiting) is waiting completion of schedule()s on all CPUs. */
+struct rcu_batch
+{
+ /* Two sets of queues: one queueing, one waiting quiescent finish */
+ int queueing;
+ /* Three queues: hard interrupt, soft interrupt, neither */
+ struct rcu_head *head[2][3];
+} __attribute__((__aligned__(SMP_CACHE_BYTES)));
+
+static struct rcu_batch rcu_batch[NR_CPUS];
+
+void call_rcu(struct rcu_head *head, void (*func)(void *head))
+{
+ unsigned cpu = smp_processor_id();
+ unsigned state;
+ struct rcu_head **headp;
+
+ head->func = func;
+ if (in_interrupt()) {
+ if (in_irq()) state = 2;
+ else state = 1;
+ } else state = 0;
+
+ /* Figure out which queue we're on. */
+ headp = &rcu_batch[cpu].head[rcu_batch[cpu].queueing][state];
+
+ atomic_inc(&rcu_pending);
+ /* Prepend to this CPU's list: no locks needed. */
+ head->next = *headp;
+ *headp = head;
+}
+
+/* Calls every callback in the waiting rcu batch. */
+void rcu_batch_done(void)
+{
+ struct rcu_head *i, *next;
+ struct rcu_batch *mybatch;
+ unsigned int q;
+
+ mybatch = &rcu_batch[smp_processor_id()];
+ /* Call callbacks: probably delete themselves, must not schedule. */
+ for (q = 0; q < 3; q++) {
+ for (i = mybatch->head[!mybatch->queueing][q]; i; i = next) {
+ next = i->next;
+ i->func(i);
+ atomic_dec(&rcu_pending);
+ }
+ mybatch->head[!mybatch->queueing][q] = NULL;
+ }
+
+ /* Start queueing on this batch. */
+ mybatch->queueing = !mybatch->queueing;
+}
+
+EXPORT_SYMBOL(call_rcu);
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal working-2.4.7-module/kernel/sched.c working-2.4.7-rcu/kernel/sched.c
--- working-2.4.7-module/kernel/sched.c Sun Jul 22 13:13:25 2001
+++ working-2.4.7-rcu/kernel/sched.c Wed Aug 29 10:23:02 2001
@@ -26,6 +26,7 @@
#include <linux/interrupt.h>
#include <linux/kernel_stat.h>
#include <linux/completion.h>
+#include <linux/rcupdate.h>
#include <asm/uaccess.h>
#include <asm/mmu_context.h>
@@ -99,12 +100,15 @@
struct schedule_data {
struct task_struct * curr;
cycles_t last_schedule;
+ int ring_count, finished_count;
} schedule_data;
char __pad [SMP_CACHE_BYTES];
-} aligned_data [NR_CPUS] __cacheline_aligned = { {{&init_task,0}}};
+} aligned_data [NR_CPUS] __cacheline_aligned = { {{&init_task,0,0,0}}};
#define cpu_curr(cpu) aligned_data[(cpu)].schedule_data.curr
#define last_schedule(cpu) aligned_data[(cpu)].schedule_data.last_schedule
+#define ring_count(cpu) aligned_data[(cpu)].schedule_data.ring_count
+#define finished_count(cpu) aligned_data[(cpu)].schedule_data.finished_count
struct kernel_stat kstat;
@@ -544,6 +548,10 @@
release_kernel_lock(prev, this_cpu);
+ if (atomic_read(&rcu_pending))
+ goto rcu_process;
+rcu_process_back:
+
/*
* 'sched_data' is protected by the fact that we can run
* only one process per CPU.
@@ -693,6 +701,19 @@
c = goodness(prev, this_cpu, prev->active_mm);
next = prev;
goto still_running_back;
+
+rcu_process:
+ /* Avoid cache line effects if value hasn't changed */
+ c = ring_count((this_cpu + 1) % smp_num_cpus) + 1;
+ if (c != ring_count(this_cpu)) {
+ /* Do subtraction to avoid int wrap corner case */
+ if (c - finished_count(this_cpu) >= 0) {
+ rcu_batch_done();
+ finished_count(this_cpu) = c + smp_num_cpus;
+ }
+ ring_count(this_cpu) = c;
+ }
+ goto rcu_process_back;
move_rr_last:
if (!prev->counter) {
-
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/
Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!newshub1-work.home.com!gehenna.pell.portland.or.us!nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Wed, 12 Sep 2001 17:15:37 +0200
From: Andrea Arcangeli <and...@suse.de>
X-To: linux-ker...@vger.kernel.org
Subject: 2.4.10pre8aa1
Message-ID: <linux.kernel.20010912171537.I695@athlon.random>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 66
The letter about the RCU patent used in GPL software is in on the way to
Linus and a copy is also in my way, so the rcu patent isn't going to be
a problem for linux users.
The rcu-2 version has probably still a bug in call_rcu, it can't harm at
the moment since nobody is recalling call_rcu but we're working on that,
also I need to merge the new updates from Dipankar and also Rusty's
approch with the schedule hook looks attractive after all, so it's work
in progress but as just said the fact it is work in progress cannot harm
anybody so you can apply it safely and in the meantime it has the
advantage of putting more eyes on the code.
Only in 2.4.10pre7aa2: 00_paride-max_sectors-2
Only in 2.4.10pre7aa2: 00_sd-max_sectors-1
Merged in mainline.
Only in 2.4.10pre8aa1: 00_alpha-personality-1
Fix compile problem with personality changes on alpha.
Only in 2.4.10pre7aa2: 00_lvm-1.0.1-rc2-1.bz2
Only in 2.4.10pre8aa1: 00_lvm-1.0.1-rc2-2.bz2
Use min() rather than min_t().
Only in 2.4.10pre8aa1: 00_nfs-delete-lock-1
Fix race condition in locks cleanup on close. (from Trond)
Only in 2.4.10pre7aa2: 00_rcu-1
Only in 2.4.10pre8aa1: 00_rcu-2
Fix uptime stats.
Only in 2.4.10pre7aa2: 00_silent-stack-overflow-7
Only in 2.4.10pre8aa1: 00_silent-stack-overflow-8
Minor cleanup.
Only in 2.4.10pre8aa1: 00_slab-microoptimize-1
Microoptimize the slab-lists handling to be as fast as the
previous version in the microbenchmarks.
Only in 2.4.10pre7aa2: 10_prefetch-5
Only in 2.4.10pre8aa1: 10_prefetch-6
Drop the x86 arch part that is included in mainline (also noticed it is
only used on PIII compiles, not sure why not on K7 and P4).
Only in 2.4.10pre8aa1: 55_uml-sys_personality-1
Fix personality syscall declaration on uml.
Only in 2.4.10pre7aa2: 60_tux-2.4.9-ac10-G7
Only in 2.4.10pre8aa1: 60_tux-2.4.9-ac10-H2
Picked last update from http://www.redhat.com/~mingo/ .
Andrea
-
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/
|