From: Dipankar Sarma <dipankar@in.ibm.com>
To: BALBIR SINGH <balbir.singh@wipro.com>
Cc: "Paul E. McKenney" <pmckenne@us.ibm.com>,
lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: RFC: patch to allow lock-free traversal of lists with insertion
Date: Tue, 9 Oct 2001 13:16:26 +0530 [thread overview]
Message-ID: <20011009131626.A10410@in.ibm.com> (raw)
In-Reply-To: <200110090155.f991tPt22329@eng4.beaverton.ibm.com> <3BC2A3B3.3020004@wipro.com>
In-Reply-To: <3BC2A3B3.3020004@wipro.com>; from balbir.singh@wipro.com on Tue, Oct 09, 2001 at 12:43:55PM +0530
On Tue, Oct 09, 2001 at 12:43:55PM +0530, BALBIR SINGH wrote:
> 1) On Alpha this code does not improve performance since we end up using spinlocks
> for my_global_data anyway, I think you already know this.
It may if you don't update very often. It depends on your
read-to-write ratio.
>
> The approach is good, but what are the pratical uses of the approach. Like u mentioned a newly
> added element may not show up in the search, searches using this method may have to search again
> and there is no way of guaranty that an element that we are looking for will be found (especially
> if it is just being added to the list).
>
> The idea is tremendous for approaches where we do not care about elements being newly added.
> It should definitely be in the Linux kernel :-)
Either you see the element or you don't. If you want to avoid duplication,
you could do a locked search before inserting it.
Like I said before, lock-less lookups are useful for read-mostly
data. Yes, updates are costly, but if they happen rarely, you still benefit.
Thanks
Dipankar
--
Dipankar Sarma <dipankar@in.ibm.com> Project: http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
next prev parent reply other threads:[~2001-10-09 7:41 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-09 1:55 RFC: patch to allow lock-free traversal of lists with insertion Paul E. McKenney
2001-10-09 2:18 ` David S. Miller
2001-10-09 6:52 ` Richard Henderson
2001-10-09 9:03 ` Rusty Russell
2001-10-09 16:11 ` Richard Henderson
2001-10-10 1:39 ` Rusty Russell
2001-10-09 7:13 ` BALBIR SINGH
2001-10-09 7:46 ` Dipankar Sarma [this message]
2001-10-09 8:21 ` BALBIR SINGH
2001-10-09 8:48 ` Dipankar Sarma
-- strict thread matches above, loose matches on Subject: below --
2001-10-09 5:27 Paul McKenney
2001-10-09 5:56 ` David S. Miller
2001-10-09 6:43 ` Richard Henderson
2001-10-09 15:24 Paul McKenney
2001-10-09 15:28 Paul McKenney
2001-10-09 15:45 Paul McKenney
2001-10-09 17:00 ` Richard Henderson
2001-10-10 3:33 ` Paul Mackerras
2001-10-10 17:02 ` Richard Henderson
2001-10-09 16:51 Manfred Spraul
2001-10-09 17:46 Paul McKenney
2001-10-09 18:01 Paul McKenney
2001-10-10 1:19 Paul McKenney
2001-10-10 1:43 ` Andrea Arcangeli
2001-10-10 21:47 Paul McKenney
2001-10-10 22:22 ` Richard Henderson
2001-10-10 22:27 ` Richard Henderson
2001-10-11 1:56 Paul E. McKenney
2001-10-12 4:14 ` Rusty Russell
2001-10-13 14:48 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011009131626.A10410@in.ibm.com \
--to=dipankar@in.ibm.com \
--cc=balbir.singh@wipro.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=pmckenne@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox