Re: SSE in libthr

If SIMD instructions are used for string proceccing, and FPU(AVX) contexts are NOT saved/restored properly on process (thread) switching, possibly processed string is destroyed by other process (thread). Can't it be a security risk? (Broken string parameter for syscalls, etc) If so, FPU (AVX) cont

Re: SSE in libthr

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

Re: SSE in libthr

On 27 March 2015 at 16:03, Alan Somers wrote: > On Fri, Mar 27, 2015 at 4:36 PM, Adrian Chadd 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'

locking issue between igmp and route code in current?

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 ifnet_

Re: SSE in libthr

On Fri, Mar 27, 2015 at 4:36 PM, Adrian Chadd 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 respectfully di

Re: SSE in libthr

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

Re: SSE in libthr

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.

Re: SSE in libthr

On Fri, Mar 27, 2015 at 01:49:03PM -0700, Rui Paulo wrote: > On Mar 27, 2015, at 12:26, 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

Re: SSE in libthr

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/SS

Re: SSE in libthr

On Mar 27, 2015, at 12:26, 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. > > In more detail: > > In libthr/thread/thr_mute

locking issue between igmp and route code in current?

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 - (view

Re: SSE in libthr

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 ___

Re: SSE in libthr

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. -adrian

SSE in libthr

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)

locking issue between igmp and route code in current?

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 - (view

Re: [PATCH] Adding backlight support for the i915 driver.

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 de

Re: 11.0-CURRENT: SCTP_MAX_CWND, lib/libc/net/sctp_sys_calls.c -r279859 vs. updating to head snaphot -r280598

On Fri, 2015-03-27 at 10:17 -0500, Michael Tuexen wrote: > > On 26 Mar 2015, at 21:36, Mark Millard 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

Re: 11.0-CURRENT: SCTP_MAX_CWND, lib/libc/net/sctp_sys_calls.c -r279859 vs. updating to head snaphot -r280598

> On 26 Mar 2015, at 21:36, Mark Millard 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 > root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODE

[PATCH] Adding backlight support for the i915 driver.

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: # s

11.0-CURRENT: DTLS1_VERSION_MAJOR, /head/crypto/openssl/ssl/ssl_asn1.c -r280297 vs. updating to head snaphot -r280598

/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 > -I/usr/src/secure/l

Re: Early use of log() does not end up in kernel msg buffer

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

Re: Mbuf leak in if_lagg.c

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_detachi

11.0-CURRENT: BIO_F_DGRAM_SCTP_WRITE, /head/crypto/openssl/crypto/bio/bio_err.c -r280297 vs. updating to head snaphot -r280598

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 the

11.0-CURRENT: SBUF_INCLUDENUL, /head/sys/kern/subr_sbuf.c -r280193 vs. updating to head snaphot -r280598

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 the

Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

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 D