From: Rusty Russell <rusty@rustcorp.com.au>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: dipankar@in.ibm.com, linux-kernel@vger.kernel.org,
paul.mckenney@us.ibm.com
Subject: Re: [Lse-tech] Re: RFC: patch to allow lock-free traversal of lists with insertion
Date: Sat, 13 Oct 2001 17:25:27 +1000 [thread overview]
Message-ID: <E15sJAm-0005JL-00@wagner> (raw)
In-Reply-To: Your message of "Fri, 12 Oct 2001 09:56:58 PDT." <Pine.LNX.4.33.0110120948540.31692-100000@penguin.transmeta.com>
In message <Pine.LNX.4.33.0110120948540.31692-100000@penguin.transmeta.com> you
write:
> Yes. With maybe
>
> non_preempt()
> ..
> preempt()
>
> around it for the pre-emption patches.
Sure, if they want pre-emption on SMP. Of course, then they'll want
priority inheritence.
> However, you also need to make your free _free_ be aware of the count.
> Which means that the current RCU patch is really unusable for this. You
> need to have the "count" always in a generic place (put it with the hash),
> and your schedule-time free needs to do
>
> if (atomic_read(&count))
> skip_this_do_it_next_time
WTF? I'll spell it out for you again:
static inline void foo_put(struct foo *foo)
{
if (atomic_dec_and_test(foo->use))
kfree(foo);
}
Write side normal:
lock
unhash(foo)
unlock
foo_put(foo)
Write side RCU:
lock
unhash(foo)
unlock
rcu_call(foo_put, foo);
/* ie. call foo_put(foo) "later". */
That's all. Really.
> Do that, and the RCU patches may start looking usable for the real world.
I know you're under strain, but think harder please.
Rusty.
--
Premature optmztion is rt of all evl. --DK
next prev parent reply other threads:[~2001-10-13 7:29 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-10 10:06 [Lse-tech] Re: RFC: patch to allow lock-free traversal of lists with insertion Dipankar Sarma
2001-10-10 10:18 ` Linus Torvalds
2001-10-10 11:43 ` Dipankar Sarma
2001-10-12 3:27 ` Rusty Russell
2001-10-12 16:56 ` Linus Torvalds
2001-10-12 18:53 ` Dipankar Sarma
2001-10-13 7:25 ` Rusty Russell [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-10-13 14:42 Paul McKenney
2001-10-13 17:23 ` Linus Torvalds
2001-10-13 17:28 ` Linus Torvalds
2001-10-14 7:25 ` Dipankar Sarma
2001-10-13 18:42 ` Andi Kleen
2001-10-13 19:15 ` Alexander Viro
2001-10-13 20:44 ` Rusty Russell
2001-10-13 21:19 ` Rusty Russell
2001-10-11 10:34 Dipankar Sarma
2001-10-10 21:44 Paul McKenney
2001-10-10 16:00 Paul McKenney
2001-10-10 15:24 Paul McKenney
2001-10-10 16:58 ` Andrea Arcangeli
2001-10-10 17:25 ` Linus Torvalds
2001-10-12 5:06 ` Rusty Russell
2001-10-12 16:28 ` Linus Torvalds
2001-10-12 19:50 ` Al Dunsmuir
2001-10-13 1:07 ` Paul Mackerras
2001-10-13 1:54 ` Davide Libenzi
2001-10-13 2:04 ` Linus Torvalds
2001-10-13 2:31 ` Davide Libenzi
2001-10-13 2:46 ` Davide Libenzi
2001-10-13 3:30 ` Linus Torvalds
2001-10-13 2:49 ` Paul Mackerras
2001-10-13 2:00 ` Linus Torvalds
2001-10-13 7:38 ` Rusty Russell
[not found] <20011010182730.0077454b.rusty@rustcorp.com.au>
2001-10-10 9:36 ` Linus Torvalds
2001-10-11 6:50 ` Rusty Russell
2001-10-10 7:58 Dipankar Sarma
2001-10-10 7:06 Dipankar Sarma
2001-10-10 7:21 ` BALBIR SINGH
2001-10-10 9:06 ` Dipankar Sarma
2001-10-10 6:54 Dipankar Sarma
2001-10-10 4:43 Paul McKenney
2001-10-09 15:45 Paul McKenney
2001-10-10 2:05 ` [Lse-tech] " Andrea Arcangeli
2001-10-10 5:05 ` Linus Torvalds
2001-10-10 5:17 ` BALBIR SINGH
2001-10-10 5:29 ` Davide Libenzi
2001-10-10 5:46 ` Linus Torvalds
2001-10-10 6:01 ` BALBIR SINGH
2001-10-10 15:23 ` Victor Yodaiken
2001-10-10 6:16 ` Paul Mackerras
2001-10-10 6:30 ` Linus Torvalds
2001-10-10 7:36 ` Paul Mackerras
2001-10-10 15:54 ` Victor Yodaiken
2001-10-10 21:56 ` Keith Owens
2001-10-10 22:24 ` Victor Yodaiken
2001-10-10 23:46 ` David S. Miller
2001-10-11 0:24 ` Davide Libenzi
2001-10-10 11:54 ` Keith Owens
2001-10-10 13:24 ` Ivan Kokshaysky
2001-10-10 13:41 ` Andrea Arcangeli
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=E15sJAm-0005JL-00@wagner \
--to=rusty@rustcorp.com.au \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paul.mckenney@us.ibm.com \
--cc=torvalds@transmeta.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