303975 |
11-Aug-2016 |
gjb |
Copy stable/11@r303970 to releng/11.0 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, and rename it to RC1.
Update __FreeBSD_version.
Use the quarterly branch for the default FreeBSD.conf pkg(8) repo and the dvd1.iso packages population.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
302408 |
08-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
286317 |
05-Aug-2015 |
vangyzen |
Disable SSE in libthr
Clang emits SSE instructions on amd64 in the common path of pthread_mutex_unlock. If the thread does not otherwise use SSE, this usage incurs a context-switch of the FPU/SSE state, which reduces the performance of multiple real-world applications by a non-trivial amount (3-5% in one application).
Instead of this change, I experimented with eagerly switching the FPU state at context-switch time. This did not help. Most of the cost seems to be in the read/write of memory--as kib@ stated--and not in the #NM handling. I tested on machines with and without XSAVEOPT.
One counter-argument to this change is that most applications already use SIMD, and the number of applications and amount of SIMD usage are only increasing. This is absolutely true. I agree that--in general and in principle--this change is in the wrong direction. However, there are applications that do not use enough SSE to offset the extra context-switch cost. SSE does not provide a clear benefit in the current libthr code with the current compiler, but it does provide a clear loss in some cases. Therefore, disabling SSE in libthr is a non-loss for most, and a gain for some.
I refrained from disabling SSE in libc--as was suggested--because I can't make the above argument for libc. It provides a wide variety of code; each case should be analyzed separately.
https://lists.freebsd.org/pipermail/freebsd-current/2015-March/055193.html
Suggestions from: dim, jmg, rpaulo Approved by: kib (mentor) MFC after: 2 weeks Sponsored by: Dell Inc.
|
277490 |
21-Jan-2015 |
andrew |
Merge all the copies of _tcb_ctor and _tcb_dtor.
The amd64, i386, and sparc64 versions were identical, with the one difference where the former two used inline asm instead of _tcb_get. I have compared the function before and after replacing the asm with _tcb_get and found the object files to be identical.
The arm, mips, and powerpc versions were almost identical. The only difference was the powerpc version used an alignment of 1 where arm and mips used 16. As this is an increase in alignment is will be safe.
Along with this arm, mips, and powerpc all passed, when initial was true, the value returned from _tcb_get as the first argument to _rtld_allocate_tls. This would then return this pointer back to the caller. We can remove these extra calls by checking if initial is set and setting the thread control block directly. As this is what the sparc64 code does we can use it directly.
As after these observations all the architectures can now have identical code we can merge them into a common file.
Differential Revision: https://reviews.freebsd.org/D1556 Reviewed by: kib Sponsored by: The FreeBSD Foundation
|
228536 |
15-Dec-2011 |
dim |
The TCB_GET32() and TCB_GET64() macros in the i386 and amd64-specific versions of pthread_md.h have a special case of dereferencing a null pointer. Clang warns about this with:
In file included from lib/libthr/arch/i386/i386/pthread_md.c:36: lib/libthr/arch/i386/include/pthread_md.h:96:10: error: indirection of non-volatile null pointer will be deleted, not trap [-Werror,-Wnull-dereference] return (TCB_GET32(tcb_self)); ^~~~~~~~~~~~~~~~~~~ lib/libthr/arch/i386/include/pthread_md.h:73:13: note: expanded from: : "m" (*(u_int *)(__tcb_offset(name)))); \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/libthr/arch/i386/include/pthread_md.h:96:10: note: consider using __builtin_trap() or qualifying pointer with 'volatile'
Since this indirection is done relative to the fs or gs segment, to retrieve thread-specific data, it is an exception to the rule.
Therefore, add a volatile qualifier to tell the compiler we really want to dereference a zero address.
MFC after: 1 week
|
217107 |
07-Jan-2011 |
kib |
Add section .note.GNU-stack for assembly files used by 386 and amd64.
|
212516 |
13-Sep-2010 |
imp |
Merge from tbemd, with a small amount of rework: For all libthr contexts, use ${MACHINE_CPUARCH} for all libc contexts, use ${MACHINE_ARCH} if it exists, otherwise use ${MACHINE_CPUARCH} Move some common code up a layer (the .PATH statement was the same in all the arch submakefiles).
# Hope she hasn't busted powerpc64 with this...
|
177853 |
02-Apr-2008 |
davidxu |
Replace function _umtx_op with _umtx_op_err, the later function directly returns errno, because errno can be mucked by user's signal handler and most of pthread api heavily depends on errno to be correct, this change should improve stability of the thread library.
|
176226 |
13-Feb-2008 |
obrien |
style.Makefile(5)
|
165241 |
15-Dec-2006 |
davidxu |
- Remove variable _thr_scope_system, all threads are system scope. - Rename _thr_smp_cpus to boolean variable _thr_is_smp. - Define CPU_SPINWAIT macro for each arch, only X86 supports it.
|
157462 |
04-Apr-2006 |
davidxu |
Remove declaration of _thr_initial from MD header file, it is no longer needed.
|
157461 |
04-Apr-2006 |
davidxu |
Simplify _get_curthread() and _tcb_ctor because libc and rtld now already allocate thread pointer space in tls block for initial thread. Only i386 and amd64 have been done, others still have to be tested.
|
144518 |
02-Apr-2005 |
davidxu |
Import my recent 1:1 threading working. some features improved includes: 1. fast simple type mutex. 2. __thread tls works. 3. asynchronous cancellation works ( using signal ). 4. thread synchronization is fully based on umtx, mainly, condition variable and other synchronization objects were rewritten by using umtx directly. those objects can be shared between processes via shared memory, it has to change ABI which does not happen yet. 5. default stack size is increased to 1M on 32 bits platform, 2M for 64 bits platform. As the result, some mysql super-smack benchmarks show performance is improved massivly.
Okayed by: jeff, mtm, rwatson, scottl
|
134050 |
19-Aug-2004 |
davidxu |
Add AMD64 support code.
|