lkml.org 
[lkml]   [2005]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] SMP alternatives


On Wed, 23 Nov 2005, Eric W. Biederman wrote:
>
> In fact for being explict we already have PROT_SEM on some architectures
> to report if we are going to use atomic operations, in the mmap. For
> x86 we would probably need to introduce a PROT_NOSEM but it is sounds
> fairly straight forward to implement.

PROT_SEM was a mistake, I feel. It's way too easy to get it wrong. You
have most architectures and environments that don't need it, and as a
result, applications simply won't have it in their sources.

I suspect that with MAP_SHARED + PROT_WRITE being pretty uncommon anyway,
we can probably find trivial patterns in the kernel. Like only one process
holding that file open - which is what you get with things that use mmap()
to write a new file (I think "ld" used to have a config option to write
files that way, for example).

And if we end up sometimes giving "lock" meaning even when it's not
needed, tough. The point of the simple hack is very much a "get 90% of the
advantage for very little effort".

Regardless, even if we get a flag like that (and the Intel people didn't
seem to dismiss the idea), it's likely a more than a few years down the
line. So it's not like this is a pressing concern ;)

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.082 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site