;
}
return 0;
}
fd = open (/proc/self/exe, O_RDONLY | O_CLOEXEC);
printf (in parent: new fd = %d\n, fd);
char buf[20];
snprintf (buf, sizeof (buf), %d, fd);
execl (/proc/self/exe, argv[0], buf, NULL);
puts (execl failed);
return 1;
}
Signed-off-by: Ulrich Drepper [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nicholas Miell wrote:
O_CLOSEONEXEC, perhaps?
Then nobody would know this is equivalent to FD_CLOEXEC. I think the
name I propose is fine.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE
to the
functionality. I cannot set the policy to default to close-on-exit in
glibc all the while the application assumes this is not the case.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGXxcK2ijCOnn
break assumptions in the
same program.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGXxm/2ijCOnn/RHQRAm+wAJ9YD6KsS6T96xChZvS/3yCwCo6+0gCgl0IY
y6OxxUcuQ8yGJsiYebkuIMY=
=tkxV
-END PGP SIGNATURE
the runtime libraries need
(not just libc, libstdc++, libxml, whatever) and vice versa. Policies
are always wrong for somebody and changing the standardized behavior is
not acceptable.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG
erred descriptor should be in the private namespace?
There are likely many many more problems and cornercases like this.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGXfD12ijCOnn/RHQRAk4nAJ0Z
nt against the rlimit?
This seems to me like a shot from the hips without thinking about other
possibilities.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGXemS2ijCOnn/RHQRAjsFAKCGhakZosSsRzCwOvru
cannot be implicitly
consumed.
All that and the other problem I mentioned earlier today about auxiliary
data. File descriptors are not the ideal interface. Elegant: yes,
ideal: no. Fro physics and math you might have learned that not every
result that looks clean and beautiful is correct.
o use
ways (recvmsg, sendmsg). With a memory based event mechanism this
auxiliary data can be stored in memory along with the event notification.
> it is a serious flexibility issue that should not be ignored. The
> unified fd space is a blessing on one hand because it's simple and
Too si
our tests but saying there are no significant
advantages is too one-sided. There is one huge advantage: the
interface. A memory-based interface is simply the best form. File
descriptors are a resource the runtime cannot transparently consume.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧
from the hips without thinking about other
possibilities.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGXemS2ijCOnn/RHQRAjsFAKCGhakZosSsRzCwOvruxECbzcwIzACeJAiY
z9ql4FJa8XTSiZzRG79ocwM=
=0E7f
should be in the private namespace?
There are likely many many more problems and cornercases like this.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGXfD12ijCOnn/RHQRAk4nAJ0Zjevd9Y0lQa/fLzKK
but saying there are no significant
advantages is too one-sided. There is one huge advantage: the
interface. A memory-based interface is simply the best form. File
descriptors are a resource the runtime cannot transparently consume.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain
). With a memory based event mechanism this
auxiliary data can be stored in memory along with the event notification.
it is a serious flexibility issue that should not be ignored. The
unified fd space is a blessing on one hand because it's simple and
Too simple.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc
consumed.
All that and the other problem I mentioned earlier today about auxiliary
data. File descriptors are not the ideal interface. Elegant: yes,
ideal: no. Fro physics and math you might have learned that not every
result that looks clean and beautiful is correct.
- --
➧ Ulrich Drepper ➧ Red Hat
I'll get to it.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGXLUk2ijCOnn/RHQRAjL0AJ0UQzNnMn8xpj7ga0OeEWUhnkhZfgCfTH+j
iQ52SLZgWwp4wmAGCy/eL
to it.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGXLUk2ijCOnn/RHQRAjL0AJ0UQzNnMn8xpj7ga0OeEWUhnkhZfgCfTH+j
iQ52SLZgWwp4wmAGCy/eLZs=
=hpyn
When the private futex support was added the compat code wasn't changed.
The result is that code using compat code which fail, e.g., because the
timeout values are not correctly passed. The following patch should
fix that.
Signed-off-by: Ulrich Drepper <[EMAIL PROTECTED]>
---
When the private futex support was added the compat code wasn't changed.
The result is that code using compat code which fail, e.g., because the
timeout values are not correctly passed. The following patch should
fix that.
Signed-off-by: Ulrich Drepper [EMAIL PROTECTED]
--- kernel
e problem is that all these cases worked nice so far. They all had
the same good performance. Now we are severely penalizing code which
mismatches condvar and mutex shared attributes. There is a good reason
why we introduced FUTEX_CMP_REQUEUE, the benefits in certain programs is
huge.
- --
➧ Ulrich D
rs can be in different processes, this setup
might make a lot of sense.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGUeRK2
to FUTEX_CMP_REQUEUE*).
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGUdYo2ijCOnn/RHQRArmXAKCdW9a/nuJun/0KjftIcMrsURNnrwCgzCf8
XGi6EzPV88DEIwHfnMfKdNg
to FUTEX_CMP_REQUEUE*).
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGUdYo2ijCOnn/RHQRArmXAKCdW9a/nuJun/0KjftIcMrsURNnrwCgzCf8
XGi6EzPV88DEIwHfnMfKdNg
be in different processes, this setup
might make a lot of sense.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGUeRK2ijCOnn
worked nice so far. They all had
the same good performance. Now we are severely penalizing code which
mismatches condvar and mutex shared attributes. There is a good reason
why we introduced FUTEX_CMP_REQUEUE, the benefits in certain programs is
huge.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444
On 5/20/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
> 1. do nothing, always use the shared futexes. Not very attractive IMO
Why do you find this non attractive ?
How is it performance critical ?
You should know better than any other that the problem is not that the
problem itself is the
recover two more (CLONE_DETACHED, CLONE_STOPPED). And we can
invent ways to add more bits.
I'm in favor of 3b but if somebody argues the costs are not justified
because the effects of using the shared futex notification isn't high
enough I can accept that, too.
- --
➧ Ulrich Drepper ➧ Red
recover two more (CLONE_DETACHED, CLONE_STOPPED). And we can
invent ways to add more bits.
I'm in favor of 3b but if somebody argues the costs are not justified
because the effects of using the shared futex notification isn't high
enough I can accept that, too.
- --
➧ Ulrich Drepper ➧ Red
On 5/20/07, Eric Dumazet [EMAIL PROTECTED] wrote:
1. do nothing, always use the shared futexes. Not very attractive IMO
Why do you find this non attractive ?
How is it performance critical ?
You should know better than any other that the problem is not that the
problem itself is the only
On 5/17/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
We don't allow loading ELF shared library from noexec points so the
same should apply to sys_uselib aswell.
Correct. But...
error = -EINVAL;
+ if (nd.mnt->mnt_flags & MNT_NOEXEC)
+ goto exit;
... the
On 5/17/07, Christoph Hellwig [EMAIL PROTECTED] wrote:
We don't allow loading ELF shared library from noexec points so the
same should apply to sys_uselib aswell.
Correct. But...
error = -EINVAL;
+ if (nd.mnt-mnt_flags MNT_NOEXEC)
+ goto exit;
... the error
futex is a normal futex. It is the job of the CMP_REQUEUE_PI call to
figure this out, select the waiter with the highest priority, and boost
the priority if necessary based on the targer futex which always is a PI
futex.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA
0x0/0x16
[] system_call+0x7e/0x83
Code: 0f 0b eb fe 48 89 7e 08 48 89 37 48 89 57 08 48 89 3a 5a c3
RIP [] __list_add+0x47/0x5b
RSP
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
/0x5b
RSP 81003cc01e78
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
futex is a normal futex. It is the job of the CMP_REQUEUE_PI call to
figure this out, select the waiter with the highest priority, and boost
the priority if necessary based on the targer futex which always is a PI
futex.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA
On 5/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
erm, I was being funny. If you randomize a binary it won't run any more.
cp /dev/random /bin/login. Oh well.
My point is, we're not being told what is being randomized here. Is it the
virtual starting address of the main executable mmap?
On 5/11/07, Andrew Morton [EMAIL PROTECTED] wrote:
erm, I was being funny. If you randomize a binary it won't run any more.
cp /dev/random /bin/login. Oh well.
My point is, we're not being told what is being randomized here. Is it the
virtual starting address of the main executable mmap? Of
e clearing in the setaffinity calls in libc.
Resetting to cache to {0,0} seems to work.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More maj
to compile (glibc-2.5.90-22 in rawhide).
If this is not available replace the sched_getcpu() call. But make sure
you pass a pointer to a cache.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
#include
#include
#include
int
main (void)
{
cpu_set_t cs
the underlying filesystem. Then the return value is
dynamic and it's the maximum (coarsest granularity) of the network
filesystem itself and the underlying filesystem.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line
Ulrich Drepper wrote:
Neil Brown wrote:
Does it also specify how to find out what granularity is used by the
filesystem? I had a need for this just recently and couldn't see any
way to extract it.
That's still on the table. We might end up with an fpathconf() solution.
OK, the pathconf
Ulrich Drepper wrote:
Neil Brown wrote:
Does it also specify how to find out what granularity is used by the
filesystem? I had a need for this just recently and couldn't see any
way to extract it.
That's still on the table. We might end up with an fpathconf() solution.
OK, the pathconf
the underlying filesystem. Then the return value is
dynamic and it's the maximum (coarsest granularity) of the network
filesystem itself and the underlying filesystem.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line
to compile (glibc-2.5.90-22 in rawhide).
If this is not available replace the sched_getcpu() call. But make sure
you pass a pointer to a cache.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
#include errno.h
#include stdio.h
#include sched.h
int
main (void)
{
cpu_set_t
in the setaffinity calls in libc.
Resetting to cache to {0,0} seems to work.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
On 5/8/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
And has Ulrich indicated that glibc would indeed go out ahead of
the kernel in this fashion?
Rik is concerned to get a glibc version which allows him to test the
improvements. That's really not a big problem. We laready have a
patch for
On 5/8/07, Andrew Morton [EMAIL PROTECTED] wrote:
And has Ulrich indicated that glibc would indeed go out ahead of
the kernel in this fashion?
Rik is concerned to get a glibc version which allows him to test the
improvements. That's really not a big problem. We laready have a
patch for this
On 5/7/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
read(2) is a cancellation point too. So if the fine userspace code issues
a random pthread_cancel() to a thread handling that, data is lost together
with the session that thread was handling.
This is absolutely not comparable. When
On 5/7/07, Davi Arnaut <[EMAIL PROTECTED]> wrote:
Anyway, we could extend epoll to be mmapable...
Welcome to kevent, well, except with a lot more ballast and awkward interfaces.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On 5/7/07, Davi Arnaut <[EMAIL PROTECTED]> wrote:
See Linus's message on this same thread.
No. I'm talking about the userlevel side, not kernel side.
If a thread is canceled *after* it returns from the syscall but before
it reports the event to the call (i.e., while still in the syscall
On 5/5/07, Davi Arnaut <[EMAIL PROTECTED]> wrote:
A google search turns up a few users. It also addresses some complaints
from Drepper.
There is a huge problem with this approach and we're back at the
inadequate interface.
select/poll/epoll are thread cancellation points. I.e., the thread
nt is less than zero, or the underlying file system does not
support this operation.
I still don't like it since len==0 shouldn't create an error (it's
inconsistent) but len<0 is already outlawed.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from t
On 5/5/07, Davi Arnaut [EMAIL PROTECTED] wrote:
A google search turns up a few users. It also addresses some complaints
from Drepper.
There is a huge problem with this approach and we're back at the
inadequate interface.
select/poll/epoll are thread cancellation points. I.e., the thread
can
On 5/7/07, Davi Arnaut [EMAIL PROTECTED] wrote:
See Linus's message on this same thread.
No. I'm talking about the userlevel side, not kernel side.
If a thread is canceled *after* it returns from the syscall but before
it reports the event to the call (i.e., while still in the syscall
On 5/7/07, Davi Arnaut [EMAIL PROTECTED] wrote:
Anyway, we could extend epoll to be mmapable...
Welcome to kevent, well, except with a lot more ballast and awkward interfaces.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
On 5/7/07, Davide Libenzi [EMAIL PROTECTED] wrote:
read(2) is a cancellation point too. So if the fine userspace code issues
a random pthread_cancel() to a thread handling that, data is lost together
with the session that thread was handling.
This is absolutely not comparable. When read/write
, or the underlying file system does not
support this operation.
I still don't like it since len==0 shouldn't create an error (it's
inconsistent) but len0 is already outlawed.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line unsubscribe
On 5/6/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
What is your position on the timerfd/signalfd/etc patches?
One more thing: recently in a network-related discussion with DaveM
et.al. we came across a situation where we want events from the
kernel. The requirement is for fast event
On 5/6/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
What is your position on the timerfd/signalfd/etc patches?
Seems to me that if we were to have fancy new event-delivery machinery
like kevent then the timerfd/signalfd work is heading in the other
direction and ultimately would prove to have
into stone by having it
in the kernel I'll not start using it.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.
extend glibc to use MADV_FREE and fall
back on MADV_DONTNEED.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
On 5/5/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
But we have our own *sane* version of WaitForMultipleObjects, and it's
called poll(2).
No, we don't. Don't start all over again. The interface of poll it
to primitive. See the kevent code, each record is, IIRC, 16 bytes in
size to return
On 5/5/07, Davide Libenzi [EMAIL PROTECTED] wrote:
But we have our own *sane* version of WaitForMultipleObjects, and it's
called poll(2).
No, we don't. Don't start all over again. The interface of poll it
to primitive. See the kevent code, each record is, IIRC, 16 bytes in
size to return
extend glibc to use MADV_FREE and fall
back on MADV_DONTNEED.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
into stone by having it
in the kernel I'll not start using it.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
On 5/6/07, Andrew Morton [EMAIL PROTECTED] wrote:
What is your position on the timerfd/signalfd/etc patches?
Seems to me that if we were to have fancy new event-delivery machinery
like kevent then the timerfd/signalfd work is heading in the other
direction and ultimately would prove to have
On 5/6/07, Andrew Morton [EMAIL PROTECTED] wrote:
What is your position on the timerfd/signalfd/etc patches?
One more thing: recently in a network-related discussion with DaveM
et.al. we came across a situation where we want events from the
kernel. The requirement is for fast event
Nick Piggin wrote:
> I literally have about 4 or 5 new page flags I'd like to add today :) I
> can't of course, because we have very few spare ones left.
I remember Rik saying that if need be he can (try to?) think of a method
to implement it without a page flag.
--
➧ Ulrich Drepper ➧ R
On 5/4/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
This is a pretty specific case, that is not very typical to find in the
usual common event loop dispatch application design.
This is where you are very wrong. Yes, it's rare in the Unix world
because non-trivial programs cannot implement
re pushed evermore to the high-end side. You'll
find many installations which today use SMP will be happy enough with
many-core UP machines.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
On 5/3/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
Why is that futexes *must* be part of the "whole solution"? Ppl needs
solutions to specific problems, not an bloated interface that, like a
giant blob, includes everything just because it exists.
Sync objects are essential parts of many
On 5/3/07, Davide Libenzi [EMAIL PROTECTED] wrote:
Why is that futexes *must* be part of the whole solution? Ppl needs
solutions to specific problems, not an bloated interface that, like a
giant blob, includes everything just because it exists.
Sync objects are essential parts of many programs
evermore to the high-end side. You'll
find many installations which today use SMP will be happy enough with
many-core UP machines.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
On 5/4/07, Davide Libenzi [EMAIL PROTECTED] wrote:
This is a pretty specific case, that is not very typical to find in the
usual common event loop dispatch application design.
This is where you are very wrong. Yes, it's rare in the Unix world
because non-trivial programs cannot implement this
Nick Piggin wrote:
I literally have about 4 or 5 new page flags I'd like to add today :) I
can't of course, because we have very few spare ones left.
I remember Rik saying that if need be he can (try to?) think of a method
to implement it without a page flag.
--
➧ Ulrich Drepper ➧ Red Hat
On 5/3/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
I thought you were talking about the poll/epoll interface in general, and
the approach on how to extend it for the very few cases that ppl asks for.
but I see we're focusing on futexes ...
Futexes must be part of the whole approach. If
On 5/2/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
99% of the fds you'll find inside an event loop you care to scale about,
are *already* fd based.
You are missing the point. To get acceptable behavior of the wakeup
it is necessary with this approach to open one descriptor _per thread_
for
On 5/2/07, Davi Arnaut <[EMAIL PROTECTED]> wrote:
The usage cases of yours are quite different from mine. We don't use a
single file descriptor to to manage various resources. The worker threads
are _not going_ to have a file descriptor, _only_ the event dispatching
(poll)
thread.
An model
On 5/2/07, Davi Arnaut [EMAIL PROTECTED] wrote:
The usage cases of yours are quite different from mine. We don't use a
single file descriptor to to manage various resources. The worker threads
are _not going_ to have a file descriptor, _only_ the event dispatching
(poll)
thread.
An model which
On 5/2/07, Davide Libenzi [EMAIL PROTECTED] wrote:
99% of the fds you'll find inside an event loop you care to scale about,
are *already* fd based.
You are missing the point. To get acceptable behavior of the wakeup
it is necessary with this approach to open one descriptor _per thread_
for a
On 5/3/07, Davide Libenzi [EMAIL PROTECTED] wrote:
I thought you were talking about the poll/epoll interface in general, and
the approach on how to extend it for the very few cases that ppl asks for.
but I see we're focusing on futexes ...
Futexes must be part of the whole approach. If they
Andi Kleen wrote:
> Nope. SSE3 != SSSE3. The additional S means Supplemential.
>
> It's probably because the few changes didn't justify a SSE4
OK, the problem is that the actual sse3 bit is misnamed. According to
Intel's docs bit 0 of ECX is "sse", the kernel uses "pni&q
Note the extra 's'. We use "sse" and "sse2", but "ssse3". I assume
it's a typo.
Signed-off-by: Ulrich Drepper <[EMAIL PROTECTED]>
--- arch/i386/kernel/cpu/proc.c 2007-02-15 11:21:18.0 -0800
+++ arch/i386/kernel/cpu/proc.c-new 2007-05-02 15:
On 5/2/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
Is it? Please do tell me more...
Come on, we went through all this. Having to do syscalls for event
retrieval plus the limited channel available for feedback (the POLL*
bits) is to limiting. This is where the kevent stuff innovated and
On 5/2/07, Davi Arnaut <[EMAIL PROTECTED]> wrote:
NO! Every single waiter of the _file descriptor_ is waked, not of the futex.
And how is this better? In this world of yours a program must have
one file descriptor for each single futex which is used like this *per
thread*. There can be
On 5/2/07, Davi Arnaut <[EMAIL PROTECTED]> wrote:
thread A:
int fd = plfutex(addr, 0);
do
poll(fdset+fd);
process network events
queue obj to thread B
if fd:
job processed
thread B:
wait_job();
process_job();
raise_event(addr);
On 5/2/07, Davi Arnaut <[EMAIL PROTECTED]> wrote:
It's quite easy to implement this scheme by write()ing the futexes all
at once but that would break the one futex per fd association. For
atomicity: if one of the futexes can't be queued, we would rollback
(unqueue) the others.
Sounds sane?
I
On 5/2/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
I understand your concerns, but *this* patch bundle extends
poll()/select()/epoll, and is not an alternative to kevent or other work in
progress, (and linux centered)
It is adding huge amounts of complexity and at the same time is not
On 5/2/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Well, poll() level edge semantic is well defined, you cannot cheat or change it.
If many threads call poll() on the same end point, they should *all* return
POLLIN/whatever status.
This means to me it's the wrong abstraction for this. We
On 5/1/07, Davi Arnaut <[EMAIL PROTECTED]> wrote:
The pollable futex approach is far superior (send and receive events from
userspace or kernel) to eventfd and fixes (supercedes) FUTEX_FD at the same
time.
[...]
You have to explain in detail how these interfaces are supposed to
work. From
On 5/1/07, Davi Arnaut [EMAIL PROTECTED] wrote:
The pollable futex approach is far superior (send and receive events from
userspace or kernel) to eventfd and fixes (supercedes) FUTEX_FD at the same
time.
[...]
You have to explain in detail how these interfaces are supposed to
work. From
On 5/2/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Well, poll() level edge semantic is well defined, you cannot cheat or change it.
If many threads call poll() on the same end point, they should *all* return
POLLIN/whatever status.
This means to me it's the wrong abstraction for this. We had
On 5/2/07, Eric Dumazet [EMAIL PROTECTED] wrote:
I understand your concerns, but *this* patch bundle extends
poll()/select()/epoll, and is not an alternative to kevent or other work in
progress, (and linux centered)
It is adding huge amounts of complexity and at the same time is not
On 5/2/07, Davi Arnaut [EMAIL PROTECTED] wrote:
It's quite easy to implement this scheme by write()ing the futexes all
at once but that would break the one futex per fd association. For
atomicity: if one of the futexes can't be queued, we would rollback
(unqueue) the others.
Sounds sane?
I
On 5/2/07, Davi Arnaut [EMAIL PROTECTED] wrote:
thread A:
int fd = plfutex(addr, 0);
do
poll(fdset+fd);
process network events
queue obj to thread B
if fd:
job processed
thread B:
wait_job();
process_job();
raise_event(addr);
On 5/2/07, Davi Arnaut [EMAIL PROTECTED] wrote:
NO! Every single waiter of the _file descriptor_ is waked, not of the futex.
And how is this better? In this world of yours a program must have
one file descriptor for each single futex which is used like this *per
thread*. There can be
On 5/2/07, Davide Libenzi [EMAIL PROTECTED] wrote:
Is it? Please do tell me more...
Come on, we went through all this. Having to do syscalls for event
retrieval plus the limited channel available for feedback (the POLL*
bits) is to limiting. This is where the kevent stuff innovated and
Note the extra 's'. We use sse and sse2, but ssse3. I assume
it's a typo.
Signed-off-by: Ulrich Drepper [EMAIL PROTECTED]
--- arch/i386/kernel/cpu/proc.c 2007-02-15 11:21:18.0 -0800
+++ arch/i386/kernel/cpu/proc.c-new 2007-05-02 15:31:17.0 -0700
@@ -46,7 +46,7
Andi Kleen wrote:
Nope. SSE3 != SSSE3. The additional S means Supplemential.
It's probably because the few changes didn't justify a SSE4
OK, the problem is that the actual sse3 bit is misnamed. According to
Intel's docs bit 0 of ECX is sse, the kernel uses pni. Too bad.
--
➧ Ulrich
On 5/1/07, Theodore Tso <[EMAIL PROTECTED]> wrote:
The question is should we use setrlimit() to set the per-thread CPU
limit, given that we would need some separate interface to set signal
that should be sent.
Is there any reason why we should have the interface specify whether
the signal
301 - 400 of 743 matches
Mail list logo
