From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>, <mingo@elte.hu>,
Matthew Kirkwood <matthew@hairy.beasts.org>,
Benjamin LaHaise <bcrl@redhat.com>,
David Axmark <david@mysql.com>,
William Lee Irwin III <wli@holomorphy.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Lightweight userspace semaphores...
Date: 28 Feb 2002 21:56:45 -0700 [thread overview]
Message-ID: <m1r8n43mya.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.LNX.4.33.0202241719330.1420-100000@home.transmeta.com>
In-Reply-To: <Pine.LNX.4.33.0202241719330.1420-100000@home.transmeta.com>
Linus Torvalds <torvalds@transmeta.com> writes:
> On Mon, 25 Feb 2002, Rusty Russell wrote:
> >
> > Bugger. How about:
> >
> > sys_sem_area(void *pagestart, size_t len)
> > sys_unsem_area(void *pagestart, size_t len)
> >
> > Is that sufficient? Is sys_unsem_area required at all?
>
> The above is sufficient, but I would personally actually prefer an
> interface more like
Hmm. My preference is for something like
mprotect(start, len, PROT_SEM | PROT_READ | PROT_WRITE);
And then
#ifdef PROT_SEM && PROT_SEM
mprotect ....
#else
/* This architecture needs not special support skip the mprotect...
#endif
> fd = sem_initialize();
> mmap(fd, ...)
> ..
> munmap(..)
>
> which gives you a handle for the semaphore.
Ouch.
The common case for a decent lock is the uncontended case. In which
case you only need kernel support on demand. What you suggest would
create kernel data structures for all of the uncontended locks. That
sounds heavy. Especially as the memory on most architectures is already
safe to use for locks.
So if nothing else can we separate the two cases of having user space
memory safe for user space spin locks. And how to setup a wait queue
of user space waiters on when we need to wait?
Eric
next prev parent reply other threads:[~2002-03-01 5:06 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-23 3:47 [PATCH] Lightweight userspace semaphores Rusty Russell
2002-02-23 15:03 ` Ingo Molnar
2002-02-23 18:20 ` Linus Torvalds
2002-02-23 18:28 ` Larry McVoy
2002-02-23 20:31 ` Ingo Molnar
2002-02-23 21:22 ` Alan Cox
2002-02-26 16:09 ` Hubertus Franke
2002-02-24 23:29 ` Rusty Russell
2002-02-24 23:48 ` Linus Torvalds
2002-02-25 1:10 ` Rusty Russell
2002-02-25 1:23 ` Linus Torvalds
2002-02-25 13:14 ` Alan Cox
2002-02-25 16:11 ` Linus Torvalds
2002-02-25 16:39 ` Alan Cox
2002-02-25 16:32 ` Benjamin LaHaise
2002-02-25 17:42 ` Alan Cox
2002-02-25 18:23 ` Hubertus Franke
2002-02-25 20:57 ` Hubertus Franke
2002-03-03 7:07 ` Rusty Russell
2002-02-25 17:06 ` Linus Torvalds
2002-02-25 17:31 ` Alan Cox
2002-02-25 17:20 ` Linus Torvalds
2002-02-25 17:50 ` Alan Cox
2002-02-25 17:44 ` Linus Torvalds
2002-02-25 18:06 ` Alan Cox
2002-02-25 19:31 ` Linus Torvalds
2002-02-24 4:57 ` Daniel Phillips
2002-02-25 19:51 ` Hubertus Franke
2002-02-26 12:15 ` [PATCH] 2.5.5 IDE clean 14 Martin Dalecki
2002-02-26 21:49 ` Keith Owens
2002-02-27 10:08 ` Martin Dalecki
2002-03-01 4:56 ` Eric W. Biederman [this message]
2002-03-02 14:54 ` [PATCH] Lightweight userspace semaphores Pavel Machek
2002-02-25 15:00 ` Hubertus Franke
2002-02-27 0:24 ` Rusty Russell
2002-02-27 15:53 ` Hubertus Franke
2002-03-01 0:24 ` Richard Henderson
2002-03-01 2:00 ` Hubertus Franke
2002-02-27 16:29 ` Hubertus Franke
2002-03-02 14:50 ` Hubertus Franke
2002-03-03 13:30 ` Rusty Russell
2002-03-04 16:51 ` Hubertus Franke
2002-03-05 4:41 ` Rusty Russell
2002-03-01 4:44 ` Eric W. Biederman
-- strict thread matches above, loose matches on Subject: below --
2002-02-27 8:43 [PATCH] Lightweight userspace semphores Martin Wirth
2002-02-27 15:24 ` Hubertus Franke
2002-02-27 17:17 ` Martin Wirth
2002-02-27 19:04 ` Hubertus Franke
[not found] ` <3C7FDF76.9040903@dlr.de>
2002-03-02 14:08 ` [PATCH] Lightweight userspace semaphores Hubertus Franke
[not found] <20020227163834.GF322@reload.nmd.msu.ru>
2002-02-27 16:58 ` Hubertus Franke
[not found] ` <20020227173307.GH322@reload.nmd.msu.ru>
2002-02-27 22:09 ` Hubertus Franke
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=m1r8n43mya.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=bcrl@redhat.com \
--cc=david@mysql.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@hairy.beasts.org \
--cc=mingo@elte.hu \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@transmeta.com \
--cc=wli@holomorphy.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