From: Andrea Arcangeli <andrea@suse.de>
To: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] 2.4.4 alpha semaphores optimization
Date: Fri, 4 May 2001 19:16:23 +0200 [thread overview]
Message-ID: <20010504191623.F22820@athlon.random> (raw)
In-Reply-To: <20010503194747.A552@jurassic.park.msu.ru> <20010503192848.V1162@athlon.random> <20010504131528.A2228@jurassic.park.msu.ru> <20010504163359.F3762@athlon.random> <20010504210233.A653@jurassic.park.msu.ru>
In-Reply-To: <20010504210233.A653@jurassic.park.msu.ru>; from ink@jurassic.park.msu.ru on Fri, May 04, 2001 at 09:02:33PM +0400
On Fri, May 04, 2001 at 09:02:33PM +0400, Ivan Kokshaysky wrote:
> But I can't imagine how this "feature" could be useful in a real life :-)
It will be required by the time we can fork more than 2^16 tasks (which
I'm wondering if it could be just the case if you use CLONE_PID as
root, I didn't checked the code yet to be sure).
> You meant "the fast path", I guess? Then it's true. However with those
Yes, I guess the slow path is quite painful to maintain, however I'd add
at least the __builtin_expect() so it gets optimized by 2.96 and 3.[01].
> atomic functions code is much more readable.
Your attached code is nice enough IMHO ;).
> Anyway, I've attached asm-alpha/rwsem_xchgadd.h for your implementation.
Sweet, thanks.
> However I got processes in D state early on boot with it -- maybe
> I've made a typo somewhere...
It has to be a bug in a non contention case then, or maybe you run some
threaded app during boot? Note that my version is a bit different than
David's one, my fast path has less requirements in up_write and so it
can be implemented with less instructions. I will check and integrate
your code soon into my patch, thanks. If you find the bug meanwhile let
me know (to beat it hard you can use my userspace threaded app that
faults and mmap/munmap in loop from dozen of threads).
Andrea
next prev parent reply other threads:[~2001-05-04 17:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-03 15:47 [patch] 2.4.4 alpha semaphores optimization Ivan Kokshaysky
2001-05-03 17:28 ` Andrea Arcangeli
2001-05-04 9:15 ` Ivan Kokshaysky
2001-05-04 14:33 ` Andrea Arcangeli
2001-05-04 17:02 ` Ivan Kokshaysky
2001-05-04 17:16 ` Andrea Arcangeli [this message]
2001-05-04 9:22 ` David Howells
2001-05-04 9:54 ` Ivan Kokshaysky
2001-05-04 16:46 ` Ivan Kokshaysky
2001-05-04 21:12 ` Richard Henderson
2001-05-05 13:55 ` Ivan Kokshaysky
2001-05-06 6:55 ` Ivan Kokshaysky
2001-05-04 21:13 ` Richard Henderson
2001-05-05 14:17 ` Ivan Kokshaysky
2001-05-05 17:06 ` __builtin_expect vs inlining Richard Henderson
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=20010504191623.F22820@athlon.random \
--to=andrea@suse.de \
--cc=ink@jurassic.park.msu.ru \
--cc=linux-kernel@vger.kernel.org \
/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