292124 |
11-Dec-2015 |
br |
Start support for the RISC-V 64-bit architecture developed by UC Berkeley.
RISC-V is a new ISA designed to support computer research and education, and is now become a standard open architecture for industry implementations.
This is a minimal set of changes required to run 'make kernel-toolchain' using external (GNU) toolchain.
The FreeBSD/RISC-V project home: https://wiki.freebsd.org/riscv.
Reviewed by: andrew, bdrewery, emaste, imp Sponsored by: DARPA, AFRL Sponsored by: HEIF5 Differential Revision: https://reviews.freebsd.org/D4445
|
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.
|
280259 |
19-Mar-2015 |
andrew |
Start to import support for the AArch64 architecture from ARM. This change only adds support for kernel-toolchain, however it is expected further changes to add kernel and userland support will be committed as they are reviewed.
As our copy of binutils is too old the devel/aarch64-binutils port needs to be installed to pull in a linker.
To build either TARGET needs to be set to arm64, or TARGET_ARCH set to aarch64. The latter is set so uname -p will return aarch64 as existing third party software expects this.
Differential Revision: https://reviews.freebsd.org/D2005 Relnotes: Yes Sponsored by: The FreeBSD Foundation
|
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
|
223228 |
18-Jun-2011 |
marius |
Merge from r161730: o Set TP using inline assembly to avoid dead code elimination. o Eliminate _tcb.
Merge from r161840: Stylize: avoid using a global register variable.
Merge from r157461: Simplify _get_curthread() and _tcb_ctor because libc and rtld now already allocate thread pointer space in tls block for initial thread.
Merge from r177853: 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.
MFC after: 1 week
|
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.
|
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
|
134051 |
19-Aug-2004 |
davidxu |
Adjust code to support AMD64, on AMD64, thread needs to set fsbase by itself before it can execute any other code, so new thread should be created with all signals are masked until after fsbase is set.
|
126643 |
05-Mar-2004 |
markm |
Make NULL a (void*)0 whereever possible, and fix the warnings(-Werror) that this provokes. "Wherever possible" means "In the kernel OR NOT C++" (implying C).
There are places where (void *) pointers are not valid, such as for function pointers, but in the special case of (void *)0, agreement settles on it being OK.
Most of the fixes were NULL where an integer zero was needed; many of the fixes were NULL where ascii <nul> ('\0') was needed, and a few were just "other".
Tested on: i386 sparc64
|
115203 |
21-May-2003 |
mtm |
o Make the defenition of _set_curthread() match its declaration in thr_private.h
o Lock down the ldt_entries array and ldt_free, which points to the next free slot. As noted in the comments, it's necessary to special case the initial_thread because %gs is not setup for it yet. This is ok because that early in the program there won't be any reentrancy issues anyways.
Approved by: re/blanket libthr
|