Basic context:
# freebsd-version -ku; uname -apKU
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21
05:15:23 PDT 2015 root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG
powerpc powerpc64 1100062 1100062
The problem:
Summary of
Basic context:
# freebsd-version -ku; uname -apKU
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21
05:15:23 PDT 2015 root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG
powerpc powerpc64 1100062 1100062
The problem:
Summary of
On 26 mar 2015, at 22:00, Jakob Alvermark wrote:
On Tue, March 24, 2015 00:29, Hans Petter Selasky wrote:
Hi,
Without the attached kernel patch(es), Xorg starts consuming alot of CPU
and becomes very unresponsive and unusable.
Using ktrace reveals that X-org is issuing
Le jeudi 26 mars 2015, 23:10:49 Andrey V. Elsukov a écrit :
On 26.03.2015 22:42, Andrey V. Elsukov wrote:
If lp_detaching is non 0, the mbuf pointer is set to NULL without m_freem
it.
Can you look at this ?
Hi,
what you thing about this patch?
lp_detaching can be non zero in
On 03/26/2015 23:20, Eric Badger wrote:
Using log(9) when no process is reading the log results in the message
going only to the console (contrast with printf(9), which goes to the
console and to the kernel message buffer in this case). I believe it is
truer to the semantics of logging for
/head/crypto/openssl/ssl/ssl_asn1.c has a similar issue to
/head/crypto/openssl/crypto/bio/bio_err.c but relative to:
/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -fpic -DPIC -O2 -pipe
-DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libssl/../../../crypto/openssl
This patch exposes the backlight support via a sysctl:
set the backlight to 10%:
# sysctl hw.dri.0.i915_backlight=10
hw.dri.0.i915_backlight: 25 - 10
set the backlight to 50%:
# sysctl hw.dri.0.i915_backlight=50
hw.dri.0.i915_backlight: 10 - 50
decrease the current backlight value:
#
Hi,
I noticed the following checkins to route.c in current, and was wondering if
they have barring on the deadlock documented below:
Revision 274589 http://svnweb.freebsd.org/base?view=revisionrevision=274589
- (view
On Fri, 2015-03-27 at 10:17 -0500, Michael Tuexen wrote:
On 26 Mar 2015, at 21:36, Mark Millard mar...@dsl-only.net wrote:
Basic context:
# freebsd-version -ku; uname -apKU
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21
On 03/27/15 16:01, Ranjan1018 . wrote:
This patch exposes the backlight support via a sysctl:
set the backlight to 10%:
# sysctl hw.dri.0.i915_backlight=10
hw.dri.0.i915_backlight: 25 - 10
set the backlight to 50%:
# sysctl hw.dri.0.i915_backlight=50
hw.dri.0.i915_backlight: 10 - 50
On 26 Mar 2015, at 21:36, Mark Millard mar...@dsl-only.net wrote:
Basic context:
# freebsd-version -ku; uname -apKU
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21
05:15:23 PDT 2015
In a nutshell:
Clang emits SSE instructions on amd64 in the common path of
pthread_mutex_unlock. This reduces performance by a non-trivial amount. I'd
like to disable SSE in libthr.
In more detail:
In libthr/thread/thr_mutex.c, we find the following:
#define MUTEX_INIT_LINK(m)
Wow. I remember seeing this in the work application - all packet
pushing in userland, but there are locks being acquired. I was
wondering what exactly was triggering the FPU save/restore code. Now I
know.
Yes, if there are no other objections, I'd love to see this in -HEAD
and stable/10.
On Fri, 27 Mar 2015, Eric van Gyzen wrote:
In a nutshell:
Clang emits SSE instructions on amd64 in the common path of
pthread_mutex_unlock. This reduces performance by a non-trivial amount. I'd
like to disable SSE in libthr.
This makes sense to me.
--
DE
Hi,
I noticed the following checkins to route.c in current, and was wondering if
they have barring on the deadlock documented below:
Revision 274589 http://svnweb.freebsd.org/base?view=revisionrevision=274589
- (view
On Mar 27, 2015, at 12:26, Eric van Gyzen vangy...@freebsd.org wrote:
In a nutshell:
Clang emits SSE instructions on amd64 in the common path of
pthread_mutex_unlock. This reduces performance by a non-trivial amount. I'd
like to disable SSE in libthr.
In more detail:
In
On Fri, Mar 27, 2015 at 03:26:17PM -0400, Eric van Gyzen wrote:
In a nutshell:
Clang emits SSE instructions on amd64 in the common path of
pthread_mutex_unlock. This reduces performance by a non-trivial
amount. I'd like to disable SSE in libthr.
How about saving and restoring the FPU/SSE
On 03/27/2015 16:49, Rui Paulo wrote:
Regarding your patch, I think we should disable even more, if possible. How
about:
CFLAGS+=-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3
Yes, I was considering copying all of the similar flags that we use in the
kernel. That seems wise.
On Fri, Mar 27, 2015 at 01:49:03PM -0700, Rui Paulo wrote:
On Mar 27, 2015, at 12:26, Eric van Gyzen vangy...@freebsd.org wrote:
In a nutshell:
Clang emits SSE instructions on amd64 in the common path of
pthread_mutex_unlock. This reduces performance by a non-trivial amount.
I'd
hi,
please don't try to microoptimise crap like strlen().
The TL;DR for performant high-throughput code is: if strlen() or
memcpy() is the thing that's costing you the most, you're doing it
wrong.
-adrian
___
freebsd-current@freebsd.org mailing list
On Fri, Mar 27, 2015 at 4:36 PM, Adrian Chadd adr...@freebsd.org wrote:
hi,
please don't try to microoptimise crap like strlen().
The TL;DR for performant high-throughput code is: if strlen() or
memcpy() is the thing that's costing you the most, you're doing it
wrong.
-adrian
I
Hi,
I realized that I hadn’t copied the other half of the locking issue mentioned
earlier..
Lars
Mon Mar 23 12:42:15 CDT 2015
lock order reversal:
1st 0xf80003d62190 if_addr_lock (if_addr_lock) @
/u/lars/sandbox/builds/current_10032015/sys/netinet/igmp.c:1714
2nd 0x80e387b0
On 27 March 2015 at 16:03, Alan Somers asom...@freebsd.org wrote:
On Fri, Mar 27, 2015 at 4:36 PM, Adrian Chadd adr...@freebsd.org wrote:
hi,
please don't try to microoptimise crap like strlen().
The TL;DR for performant high-throughput code is: if strlen() or
memcpy() is the thing that's
Possibly related information.
Recently, I tried to build world/kernel (head, r280410, amd64) with
CPUTYPE setting in make.conf. Real CPU is sandybridge (corei7-avx).
Running in VirtualBox VM, installworld fails with CPUTYPE?=corei7-avx,
while with CPUTYPE?=corei7 everything goes OK.
*Rebooting
24 matches
Mail list logo
