| Age | Commit message (Collapse) | Author |
|---|
|
From: Joe Korty <joe.korty@ccur.com>
The API for get_compat_timespec / put_compat_timespec is incorrect, it
forces a caller with const args to (incorrectly) cast. The posix message
queue patch is one such caller.
|
|
From: Arun Sharma <arun.sharma@intel.com>
- Several instances where we were using pid_t instead of uid_t
- If the caller passed a NULL `oldact' pointer into sys_sigprocmask then
don't try to write the old sigmask there.
|
|
|
|
Add 32bit->64bit conversion functions for POSIX timers.
I kept timer_create architecture specific, because it does signal specific
stuff which is not portable enough for generic compat.
|
|
From: Peter Chubb <peterc@gelato.unsw.edu.au>
Currently, do_setitimer() is used in several files, but doesn't appear
in any header. Thus its declaration is repeated in some files, and
its use causes a warning in others (because there is no declaration
present).
This patch:
-- adds a couple of declarations to linux/times.h
-- removes the (now duplicate) declarations from other files.
|
|
From: Anton Blanchard <anton@samba.org>
On success getaffinity should return the size of mask. It looks like
Randy's patch (which fixed a bogus return) missed this bit.
In reality I'm not sure if we care, and with cpu bitmasks this stuff is
going to break.
|
|
From: rwhron@earthlink.net
It returns sizeof(compat_ulong_t) even if put_user() faulted.
|
|
I must not ignore compiler warnings.
I must not ignore compiler warnings.
I must not ignore compiler warnings.
|
|
compat_sys_getrusage was returning the result of a logical or. Make
it return the result of sys_getrusage if it fails or -EFAULT if we
cant write it out to userspace.
|
|
sys_wait4 can return a pid and in this case we want to copy the struct
rusage out to userspace.
|
|
|
|
From: Christopher Hoover <ch@murgatroid.com>
Not everyone needs futex support, so it should be optional. This is needed
for small platforms.
|
|
This addresses a futex related SMP scalability problem of
glibc. A number of regressions have been reported to the NTPL mailing list
when going to many CPUs, for applications that use condition variables and
the pthread_cond_broadcast() API call. Using this functionality, testcode
shows a slowdown from 0.12 seconds runtime to over 237 seconds (!)
runtime, on 4-CPU systems.
pthread condition variables use two futex-backed mutex-alike locks: an
internal one for the glibc CV state itself, and a user-supplied mutex
which the API guarantees to take in certain codepaths. (Unfortunately the
user-supplied mutex cannot be used to protect the CV state, so we've got
to deal with two locks.)
The cause of the slowdown is a 'swarm effect': if lots of threads are
blocked on a condition variable, and pthread_cond_broadcast() is done,
then glibc first does a FUTEX_WAKE on the cv-internal mutex, then down a
mutex_down() on the user-supplied mutex. Ie. a swarm of threads is created
which all race to serialize on the user-supplied mutex. The more threads
are used, the more likely it becomes that the scheduler will balance them
over to other CPUs - where they just schedule, try to lock the mutex, and
go to sleep. This 'swarm effect' is purely technical, a side-effect of
glibc's use of futexes, and the imperfect coupling of the two locks.
the solution to this problem is to not wake up the swarm of threads, but
'requeue' them from the CV-internal mutex to the user-supplied mutex. The
attached patch adds the FUTEX_REQUEUE feature FUTEX_REQUEUE requeues N
threads from futex address A to futex address B.
This way glibc can wake up a single thread (which will take the
user-mutex), and can requeue the rest, with a single system-call.
Ulrich Drepper has implemented FUTEX_REQUEUE support in glibc, and a
number of people have tested it over the past couple of weeks. Here are
the measurements done by Saurabh Desai:
System: 4xPIII 700MHz
./cond-perf -r 100 -n 200: 1p 2p 4p
Default NPTL: 0.120s 0.211s 237.407s
requeue NPTL: 0.124s 0.156s 0.040s
./cond-perf -r 1000 -n 100:
Default NPTL: 0.276s 0.412s 0.530s
requeue NPTL: 0.349s 0.503s 0.550s
./pp -v -n 128 -i 1000 -S 32768:
Default NPTL: 128 games in 1.111s 1.270s 16.894s
requeue NPTL: 128 games in 1.111s 1.959s 2.426s
./pp -v -n 1024 -i 10 -S 32768:
Default NPTL: 1024 games in 0.181s 0.394s incompleted 2m+
requeue NPTL: 1024 games in 0.166s 0.254s 0.341s
the speedup with increasing number of threads is quite significant, in the
128 threads, case it's more than 8 times. In the cond-perf test, on 4 CPUs
it's almost infinitely faster than the 'swarm of threads' catastrophy
triggered by the old code.
|
|
|
|
This one gets rid of sys32_{get,set}affinity in favor of a unified
compat implementation.
|
|
Fix compile errors after futex merge.
|
|
This is the generic part of the patch and the architecture specific parts
I have been asked to forward directly to you.
|
|
This creates compat_sys_sigpending and compat_sys_sigprocmask and
patches sent to maintainers remove all the arch specific versions.
|
|
Andi Kleen asked for these two, so here they are. This is the generic
part of creating compat functions for timespec get/put.
|
|
This renames more types and moves them into asm/compat.h and also
consolidates sys32_new{stat,fstat,lstat}.
|
|
This patch creates compat_sys_times and a few more compability types.
|
|
Fix for the compatibility layer for NULL 'remaining time' pointer.
|
|
|
|
This is the generic part of the start of the compatibility syscall
layer. I think I have made it generic enough that each architecture can
define what compatibility means.
To use this, an architecture must create asm/compat.h and provide
typedefs for (currently) 'compat_time_t', 'struct compat_timeval' and
'struct compat_timespec'.
|
