Lai Jiangshan (supporter:SLEEPABLE READ-CO...)
> "Paul E. McKenney" (supporter:SLEEPABLE
> READ-CO...)
> Dipankar Sarma (supporter:READ-COPY UPDATE...)
> linux-kernel@vger.kernel.org (open list:SLEEPABLE READ-CO...)
>
> With the below change, it includes Josh, as expe
. McKenney paul...@linux.vnet.ibm.com (supporter:SLEEPABLE
READ-CO...)
Dipankar Sarma dipan...@in.ibm.com (supporter:READ-COPY UPDATE...)
linux-kernel@vger.kernel.org (open list:SLEEPABLE READ-CO...)
With the below change, it includes Josh, as expected based on the R:
entry I had previously added
On Thu, Apr 11, 2013 at 11:27:27AM -0700, Paul E. McKenney wrote:
> On Thu, Apr 11, 2013 at 10:14:28AM -0700, Arjan van de Ven wrote:
> > >+2.Many architectures will place dyntick-idle CPUs into deep sleep
> > >+ states, which further degrades from-idle transition latencies.
> > >+
> > I
On Thu, Apr 11, 2013 at 11:27:27AM -0700, Paul E. McKenney wrote:
On Thu, Apr 11, 2013 at 10:14:28AM -0700, Arjan van de Ven wrote:
+2.Many architectures will place dyntick-idle CPUs into deep sleep
+ states, which further degrades from-idle transition latencies.
+
I think this
On Tue, Oct 16, 2007 at 10:20:37AM -0700, Linus Torvalds wrote:
> On Tue, 16 Oct 2007, Gautham R Shenoy wrote:
>
> Well, afaik, the patch series is fairly clean, and I'm obviously perfectly
> happy with the approach, so I have no objections.
>
> But it looks buggy. This:
>
> +static
On Tue, Oct 16, 2007 at 10:20:37AM -0700, Linus Torvalds wrote:
On Tue, 16 Oct 2007, Gautham R Shenoy wrote:
Well, afaik, the patch series is fairly clean, and I'm obviously perfectly
happy with the approach, so I have no objections.
But it looks buggy. This:
+static void
On Fri, Sep 21, 2007 at 12:17:21AM -0400, Steven Rostedt wrote:
> [ continued here from comment on patch 1]
>
> On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
> > /* softirq mask and active fields moved to irq_cpustat_t in
> > diff -urpNa -X dontdiff
> >
On Fri, Sep 21, 2007 at 12:17:21AM -0400, Steven Rostedt wrote:
[ continued here from comment on patch 1]
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
/* softirq mask and active fields moved to irq_cpustat_t in
diff -urpNa -X dontdiff
On Tue, Aug 07, 2007 at 11:52:26AM -0700, Paul E. McKenney wrote:
> The combination of CPU hotplug and PREEMPT_RCU has resulted in deadlocks
> due to the migration-based implementation of synchronize_sched() in -rt.
> This experimental patch maps synchronize_sched() back onto Classic RCU,
>
On Tue, Aug 07, 2007 at 11:52:26AM -0700, Paul E. McKenney wrote:
The combination of CPU hotplug and PREEMPT_RCU has resulted in deadlocks
due to the migration-based implementation of synchronize_sched() in -rt.
This experimental patch maps synchronize_sched() back onto Classic RCU,
On Fri, Jun 15, 2007 at 09:04:19PM +0200, Peter Zijlstra wrote:
> On Fri, 2007-06-15 at 15:00 -0400, Dmitry Torokhov wrote:
> > Hi,
> >
> > I have a piece of code that is always called under a spinlock with
> > interrups disabled. Within that piece of code I iterate through a
> > list. I have
On Fri, Jun 15, 2007 at 09:04:19PM +0200, Peter Zijlstra wrote:
On Fri, 2007-06-15 at 15:00 -0400, Dmitry Torokhov wrote:
Hi,
I have a piece of code that is always called under a spinlock with
interrups disabled. Within that piece of code I iterate through a
list. I have another piece
On Mon, May 14, 2007 at 11:48:46AM +0530, Srivatsa Vaddagiri wrote:
> On Sun, May 13, 2007 at 09:33:41AM -0700, Linus Torvalds wrote:
> > On Sun, 13 May 2007, Gautham R Shenoy wrote:
> > > RFC #1: Use get_hot_cpus()- put_hot_cpus() , which follow the
> > > well known refcounting model.
> >
> >
On Mon, May 14, 2007 at 11:48:46AM +0530, Srivatsa Vaddagiri wrote:
On Sun, May 13, 2007 at 09:33:41AM -0700, Linus Torvalds wrote:
On Sun, 13 May 2007, Gautham R Shenoy wrote:
RFC #1: Use get_hot_cpus()- put_hot_cpus() , which follow the
well known refcounting model.
Yes. And usign
On Wed, May 02, 2007 at 12:50:24PM +0100, David Howells wrote:
>
> Hi Dipankar, Rusty,
>
> I seem to have found a race between RCU and rmmod. What I see appears to be
> an RCU destructor function that has a call pending but lives in a module, gets
> deleted before the RCU callback is processed:
On Wed, May 02, 2007 at 12:50:24PM +0100, David Howells wrote:
Hi Dipankar, Rusty,
I seem to have found a race between RCU and rmmod. What I see appears to be
an RCU destructor function that has a call pending but lives in a module, gets
deleted before the RCU callback is processed:
e_name);
> -#endif /* #ifdef RCU_TRACE */
> +#endif /* #ifdef CONFIG_RCU_TRACE */
>
> EXPORT_SYMBOL_GPL(call_rcu);
> EXPORT_SYMBOL_GPL(rcu_batches_completed);
Looks good. Sorry about missing this and the late response. I am
online only periodically while I am out of town (until 10th Feb).
Acked-b
);
EXPORT_SYMBOL_GPL(rcu_batches_completed);
Looks good. Sorry about missing this and the late response. I am
online only periodically while I am out of town (until 10th Feb).
Acked-by : Dipankar Sarma [EMAIL PROTECTED]
Thanks
Dipankar
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Tue, Jan 23, 2007 at 04:32:59PM -0800, Andrew Morton wrote:
> On Tue, 16 Jan 2007 00:58:58 +0530
> Dipankar Sarma <[EMAIL PROTECTED]> wrote:
>
> > This patch implements a new version of RCU which allows its read-side
> > critical sections to be preempted
On Fri, Jan 26, 2007 at 12:17:39PM -0800, Andrew Morton wrote:
> On Sat, 27 Jan 2007 01:16:22 +0530
> Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> > > The plan is, I hope, to rip it all out and do freeze_processes() on the
> > > hotplug side, so nobody else needs to wo
On Fri, Jan 26, 2007 at 11:28:37AM -0800, Andrew Morton wrote:
> On Sat, 27 Jan 2007 00:41:13 +0530
> Dipankar Sarma <[EMAIL PROTECTED]> wrote:
>
> > Is this a good example to
> > show why per-subsystem locks might be unmaintainable ?
>
> Maybe. It might a
On Thu, Jan 25, 2007 at 02:36:45AM +0530, Dipankar Sarma wrote:
> On Wed, Jan 24, 2007 at 08:15:59AM -0800, Paul E. McKenney wrote:
>
> It should be relatively easy. Setting the offlined cpu's flags
> to neutral state should do the trick in most cases.
> I will send out the patches
On Thu, Jan 25, 2007 at 02:36:45AM +0530, Dipankar Sarma wrote:
On Wed, Jan 24, 2007 at 08:15:59AM -0800, Paul E. McKenney wrote:
It should be relatively easy. Setting the offlined cpu's flags
to neutral state should do the trick in most cases.
I will send out the patches tomorrow after
On Fri, Jan 26, 2007 at 11:28:37AM -0800, Andrew Morton wrote:
On Sat, 27 Jan 2007 00:41:13 +0530
Dipankar Sarma [EMAIL PROTECTED] wrote:
Is this a good example to
show why per-subsystem locks might be unmaintainable ?
Maybe. It might also be a good example of confused design
On Fri, Jan 26, 2007 at 12:17:39PM -0800, Andrew Morton wrote:
On Sat, 27 Jan 2007 01:16:22 +0530
Dipankar Sarma [EMAIL PROTECTED] wrote:
The plan is, I hope, to rip it all out and do freeze_processes() on the
hotplug side, so nobody else needs to worry about cpu hotplug any more
On Tue, Jan 23, 2007 at 04:32:59PM -0800, Andrew Morton wrote:
On Tue, 16 Jan 2007 00:58:58 +0530
Dipankar Sarma [EMAIL PROTECTED] wrote:
This patch implements a new version of RCU which allows its read-side
critical sections to be preempted.
Why is it selectable if CONFIG_PREEMPT=n
]>
Signed-off-by: Dipankar Sarma <[EMAIL PROTECTED]>
---
diff -puN include/linux/rcupreempt.h~rcu-preempt-trace
include/linux/rcupreempt.h
--- linux-2.6.20-rc3-mm1-rcu/include/linux/rcupreempt.h~rcu-preempt-trace
2007-01-15 15:36:56.0 +0530
+++ linux-2.6.20-rc3-mm1-rcu-
Fix a few trivial things based on review comments.
Signed-off-by: Dipankar Sarma <[EMAIL PROTECTED]>
---
diff -puN kernel/rcupreempt.c~rcu-fix-trivials kernel/rcupreempt.c
--- linux-2.6.20-rc3-mm1-rcu/kernel/rcupreempt.c~rcu-fix-trivials
2007-01-15 15:37:00.0 +0530
+++
mption.
As a consequence of keeping track of RCU readers, the readers
have a slight overhead (optimizations in the paper).
This implementation co-exists with the "classic" RCU
implementations and can be switched to at compiler.
Signed-off-by: Paul McKenney <[EMAIL PROTECTED]>
Signed-off-by:
Fix rcu_barrier() to work properly in preemptive kernel environment.
Also, the ordering of callback must be preserved while moving
callbacks to another CPU during CPU hotplug.
Signed-off-by: Dipankar Sarma <[EMAIL PROTECTED]>
---
diff -puN kernel/rcuclassic.c~rcu-fix-barriers
Finally, RCU gets its own softirq. With it being used extensively,
the per-cpu tasklet used earlier was just a softirq with overheads.
This makes things more efficient.
Signed-off-by: Dipankar Sarma <[EMAIL PROTECTED]>
---
diff -puN include/linux/interrupt.h~rcu-softirq include
This patch re-organizes the RCU code to enable multiple implementations
of RCU. Users of RCU continues to include rcupdate.h and the
RCU interfaces remain the same. This is in preparation for
subsequently merging the preepmtpible RCU implementation.
Signed-off-by: Dipankar Sarma <[EM
Andrew,
Please include this patchset for some testing in -mm.
This patchset consists of various merge candidates that would
do well to have some testing in -mm. This patchset breaks
out RCU implementation from its APIs to allow multiple
implementations, gives RCU its own softirq and finally
Andrew,
Please include this patchset for some testing in -mm.
This patchset consists of various merge candidates that would
do well to have some testing in -mm. This patchset breaks
out RCU implementation from its APIs to allow multiple
implementations, gives RCU its own softirq and finally
This patch re-organizes the RCU code to enable multiple implementations
of RCU. Users of RCU continues to include rcupdate.h and the
RCU interfaces remain the same. This is in preparation for
subsequently merging the preepmtpible RCU implementation.
Signed-off-by: Dipankar Sarma [EMAIL
Finally, RCU gets its own softirq. With it being used extensively,
the per-cpu tasklet used earlier was just a softirq with overheads.
This makes things more efficient.
Signed-off-by: Dipankar Sarma [EMAIL PROTECTED]
---
diff -puN include/linux/interrupt.h~rcu-softirq include/linux
Fix rcu_barrier() to work properly in preemptive kernel environment.
Also, the ordering of callback must be preserved while moving
callbacks to another CPU during CPU hotplug.
Signed-off-by: Dipankar Sarma [EMAIL PROTECTED]
---
diff -puN kernel/rcuclassic.c~rcu-fix-barriers kernel
.
As a consequence of keeping track of RCU readers, the readers
have a slight overhead (optimizations in the paper).
This implementation co-exists with the classic RCU
implementations and can be switched to at compiler.
Signed-off-by: Paul McKenney [EMAIL PROTECTED]
Signed-off-by: Dipankar Sarma [EMAIL PROTECTED
-by: Dipankar Sarma [EMAIL PROTECTED]
---
diff -puN include/linux/rcupreempt.h~rcu-preempt-trace
include/linux/rcupreempt.h
--- linux-2.6.20-rc3-mm1-rcu/include/linux/rcupreempt.h~rcu-preempt-trace
2007-01-15 15:36:56.0 +0530
+++ linux-2.6.20-rc3-mm1-rcu-dipankar/include/linux
Fix a few trivial things based on review comments.
Signed-off-by: Dipankar Sarma [EMAIL PROTECTED]
---
diff -puN kernel/rcupreempt.c~rcu-fix-trivials kernel/rcupreempt.c
--- linux-2.6.20-rc3-mm1-rcu/kernel/rcupreempt.c~rcu-fix-trivials
2007-01-15 15:37:00.0 +0530
+++ linux
On Sun, Dec 10, 2006 at 03:18:38PM +0100, Rafael J. Wysocki wrote:
> On Sunday, 10 December 2006 13:16, Andrew Morton wrote:
> > On Sun, 10 Dec 2006 12:49:43 +0100
>
> Hm, currently we're using the CPU hotplug to disable the nonboot CPUs before
> the freezer is called. ;-)
>
> However, we're now
On Sun, Dec 10, 2006 at 03:18:38PM +0100, Rafael J. Wysocki wrote:
On Sunday, 10 December 2006 13:16, Andrew Morton wrote:
On Sun, 10 Dec 2006 12:49:43 +0100
Hm, currently we're using the CPU hotplug to disable the nonboot CPUs before
the freezer is called. ;-)
However, we're now trying
On Thu, Sep 08, 2005 at 06:44:27PM +0530, Dinakar Guniguntala wrote:
>
>
> > On the other hand, Dinakar had more work to do than you might, because
> > he needed a complete covering (so had to round up cpus in non exclusive
> > cpusets to form more covering elements). From what I can tell, you
On Thu, Sep 08, 2005 at 06:44:27PM +0530, Dinakar Guniguntala wrote:
On the other hand, Dinakar had more work to do than you might, because
he needed a complete covering (so had to round up cpus in non exclusive
cpusets to form more covering elements). From what I can tell, you
don't
On Thu, Sep 01, 2005 at 05:48:28PM +0200, Eric Dumazet wrote:
> dentry cache uses sophisticated RCU technology (and prefetching if
> available) but touches 2 cache lines per dentry during hlist lookup.
>
> This patch moves d_hash in the same cache line than d_parent and d_name
> fields so that
On Thu, Sep 01, 2005 at 05:48:28PM +0200, Eric Dumazet wrote:
dentry cache uses sophisticated RCU technology (and prefetching if
available) but touches 2 cache lines per dentry during hlist lookup.
This patch moves d_hash in the same cache line than d_parent and d_name
fields so that :
er for nr_files, we populate files_stat.nr_files before returning
to user.
Counting files as an when they are created and destroyed (as opposed
to inside slab) allows us to correctly count open files with RCU.
Signed-off-by: Dipankar Sarma <[EMAIL PROTECTED]>
---
fs/dcache.c
to user.
Counting files as an when they are created and destroyed (as opposed
to inside slab) allows us to correctly count open files with RCU.
Signed-off-by: Dipankar Sarma [EMAIL PROTECTED]
---
fs/dcache.c |2 -
fs/file_table.c | 71
On Thu, Aug 11, 2005 at 11:30:44PM +0530, Dipankar Sarma wrote:
> When I worked on this last (a year or so ago), it seemed that I would
> need to put a number of additional structures under RCU control.
> It would be better to gradually move it towards RCU rather than
> trying make all
On Thu, Aug 11, 2005 at 06:14:51PM +0100, Christoph Hellwig wrote:
> On Wed, Aug 10, 2005 at 10:11:45AM -0700, Paul E. McKenney wrote:
> > Hello!
> >
> > This patch is an experiment in use of RCU for individual code paths that
> > read-acquire the tasklist lock, in this case, unicast signal
On Thu, Aug 11, 2005 at 06:14:51PM +0100, Christoph Hellwig wrote:
On Wed, Aug 10, 2005 at 10:11:45AM -0700, Paul E. McKenney wrote:
Hello!
This patch is an experiment in use of RCU for individual code paths that
read-acquire the tasklist lock, in this case, unicast signal delivery.
It
On Thu, Aug 11, 2005 at 11:30:44PM +0530, Dipankar Sarma wrote:
When I worked on this last (a year or so ago), it seemed that I would
need to put a number of additional structures under RCU control.
It would be better to gradually move it towards RCU rather than
trying make all the readers
On Mon, Aug 08, 2005 at 10:25:59AM -0700, Andrew Morton wrote:
> Dipankar Sarma <[EMAIL PROTECTED]> wrote:
> >
> > > But: IIRC the counters were moved to the ctor/dtor for performance
> > > reasons, I'd guess mbligh ran into cache line trashing on the
> >
On Mon, Aug 08, 2005 at 06:31:52PM +0200, Manfred Spraul wrote:
> Dipankar Sarma wrote:
>
> >Hugh, could you please try this with the experimental patch below ?
> >Manfred, is it safe to decrement nr_files in file_free()
> >instead of the destructor ?
un
it myself and see if I can reproduce it.
Thanks
Dipankar
nr_files need to decremented before the file structure is handed
over to RCU.
Signed-off-by: Dipankar Sarma <[EMAIL PROTECTED]>
---
fs/file_table.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff -puN fs/file_t
to decremented before the file structure is handed
over to RCU.
Signed-off-by: Dipankar Sarma [EMAIL PROTECTED]
---
fs/file_table.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff -puN fs/file_table.c~files-fix-nr-files fs/file_table.c
--- linux-2.6.13-rc3-mm3-fixes/fs/file_table.c
On Mon, Aug 08, 2005 at 06:31:52PM +0200, Manfred Spraul wrote:
Dipankar Sarma wrote:
Hugh, could you please try this with the experimental patch below ?
Manfred, is it safe to decrement nr_files in file_free()
instead of the destructor ? I can't see any problem.
The ctor/dtor
On Mon, Aug 08, 2005 at 10:25:59AM -0700, Andrew Morton wrote:
Dipankar Sarma [EMAIL PROTECTED] wrote:
But: IIRC the counters were moved to the ctor/dtor for performance
reasons, I'd guess mbligh ran into cache line trashing on the
filp_count_lock spinlock with reaim or something
On Sat, Apr 02, 2005 at 10:21:50PM -0800, Paul E. McKenney wrote:
> The synchronize_kernel() primitive is used for quite a few different
> purposes: waiting for RCU readers, waiting for NMIs, waiting for interrupts,
> and so on. This makes RCU code harder to read, since synchronize_kernel()
>
On Sat, Apr 02, 2005 at 10:21:50PM -0800, Paul E. McKenney wrote:
The synchronize_kernel() primitive is used for quite a few different
purposes: waiting for RCU readers, waiting for NMIs, waiting for interrupts,
and so on. This makes RCU code harder to read, since synchronize_kernel()
might
On Wed, Mar 09, 2005 at 01:29:23PM -0800, Badari Pulavarty wrote:
> On Wed, 2005-03-09 at 13:27, Dipankar Sarma wrote:
> > On Wed, Mar 09, 2005 at 10:55:58AM -0800, Badari Pulavarty wrote:
> > > Hi,
> > >
> > > We have a 8-way P-III, 16GB RAM running 2.6.
On Wed, Mar 09, 2005 at 10:55:58AM -0800, Badari Pulavarty wrote:
> Hi,
>
> We have a 8-way P-III, 16GB RAM running 2.6.8-1. We use this as
> our server to keep source code, cscopes and do the builds.
> This machine seems to slow down over the time. One thing we
> keep noticing is it keeps
On Wed, Mar 09, 2005 at 07:17:49AM -0700, Eric W. Biederman wrote:
> Vivek Goyal <[EMAIL PROTECTED]> writes:
>
> > On Tue, 2005-03-08 at 11:00 -0700, Eric W. Biederman wrote:
> >
> > This also requires, setting the kernel virtual addresses while preparing
> > the headers. KVA for linearly
On Wed, Mar 09, 2005 at 07:17:49AM -0700, Eric W. Biederman wrote:
Vivek Goyal [EMAIL PROTECTED] writes:
On Tue, 2005-03-08 at 11:00 -0700, Eric W. Biederman wrote:
This also requires, setting the kernel virtual addresses while preparing
the headers. KVA for linearly mapped region is
On Wed, Mar 09, 2005 at 10:55:58AM -0800, Badari Pulavarty wrote:
Hi,
We have a 8-way P-III, 16GB RAM running 2.6.8-1. We use this as
our server to keep source code, cscopes and do the builds.
This machine seems to slow down over the time. One thing we
keep noticing is it keeps running out
On Wed, Mar 09, 2005 at 01:29:23PM -0800, Badari Pulavarty wrote:
On Wed, 2005-03-09 at 13:27, Dipankar Sarma wrote:
On Wed, Mar 09, 2005 at 10:55:58AM -0800, Badari Pulavarty wrote:
Hi,
We have a 8-way P-III, 16GB RAM running 2.6.8-1. We use this as
our server to keep source code
and kernprof data available in lse.sourceforge.net.
Thanks
Dipankar
--
Dipankar Sarma <[EMAIL PROTECTED]> Project: http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
On Wed, May 09, 2001 at 12:30:35PM -0500, Andrew M. Theurer wrote:
> I do have ker
and kernprof data available in lse.sourceforge.net.
Thanks
Dipankar
--
Dipankar Sarma [EMAIL PROTECTED] Project: http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
On Wed, May 09, 2001 at 12:30:35PM -0500, Andrew M. Theurer wrote:
I do have kernprof ACG and lockmeter
em -
if a large number of threads share the file_struct through
CLONE_FILES, the performance of the application will deteriorate
beyond 8 CPUs (going by John's numbers). It also indicates how
sensitive can performance be to write access of shared-memory
locations like spin-waiting locks.
Thanks
Dipankar
--
gh
CLONE_FILES, the performance of the application will deteriorate
beyond 8 CPUs (going by John's numbers). It also indicates how
sensitive can performance be to write access of shared-memory
locations like spin-waiting locks.
Thanks
Dipankar
--
Dipankar Sarma ([EMAIL PROTECTED])
IBM Linux Technology
On Wed, Mar 28, 2001 at 12:51:02PM -0800, george anzinger wrote:
> Dipankar Sarma wrote:
> >
> > Also, a task could be preempted and then rescheduled on the same cpu
> > making
> > the depth counter 0 (right ?), but it could still be holding references
> > to
On Wed, Mar 28, 2001 at 12:51:02PM -0800, george anzinger wrote:
Dipankar Sarma wrote:
Also, a task could be preempted and then rescheduled on the same cpu
making
the depth counter 0 (right ?), but it could still be holding references
to data
structures to be updated using
r, the link is
http://www.rdrop.com/users/paulmck/paper/rclockpdcsproof.pdf.
Thanks
Dipankar
--
Dipankar Sarma ([EMAIL PROTECTED])
IBM Linux Technology Center
IBM Software Lab, Bangalore, India.
Project Page: http://lse.sourceforge.net
-
To unsubscribe from this list: send the line "un
experiment with both to understand the impact.
Thanks
Dipankar
--
Dipankar Sarma ([EMAIL PROTECTED])
IBM Linux Technology Center
IBM Software Lab, Bangalore, India.
Project Page: http://lse.sourceforge.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
tural" and preemptive
schedules() and ignore preemptive ones.
Pros: easy to use
Cons: Not so easy to implement. Also a low priority task that keeps
getting
preempted often can affect update side performance significantly.
I intend to experiment with both to understand the impact.
Thanks
Dipankar
--
an disable/enable preemption using these.
2. Avoid counting preemptive context switches. I am not sure
about this one though.
By the way, there is a paper on this somewhere on the web. Anyone
remember where?
If you are talking about Paul's paper, the link is
http://www.rdrop.com/users/paulmck/pa
://lse.sourceforge.net/locking/rclock.html.
Thanks
Dipankar
--
Dipankar Sarma ([EMAIL PROTECTED])
IBM Linux Technology Center
IBM India Software Lab, Bangalore, India.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
://lse.sourceforge.net/locking/rclock.html.
Thanks
Dipankar
--
Dipankar Sarma ([EMAIL PROTECTED])
IBM Linux Technology Center
IBM India Software Lab, Bangalore, India.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
78 matches
Mail list logo
