On 2013/01/16 03:45, John Baldwin wrote:
> On Tuesday, January 15, 2013 4:21:25 am David Chisnall wrote:
>> On 14 Jan 2013, at 18:58, John Baldwin wrote:
>>
>>> I'm less certain. Note that you can't inline mutex ops until you expose
>>> the mutexes themselves to userland (that is, making pthread_m
On Tuesday, January 15, 2013 4:21:25 am David Chisnall wrote:
> On 14 Jan 2013, at 18:58, John Baldwin wrote:
>
> > I'm less certain. Note that you can't inline mutex ops until you expose
> > the mutexes themselves to userland (that is, making pthread_mutex_t not
> > be opaque).
>
> This is one
On 14 Jan 2013, at 18:58, John Baldwin wrote:
> I'm less certain. Note that you can't inline mutex ops until you expose
> the mutexes themselves to userland (that is, making pthread_mutex_t not
> be opaque).
This is one of the things that will be required anyway if we wish to support
process-sh
On Monday, January 14, 2013 1:24:04 pm David Chisnall wrote:
> On 14 Jan 2013, at 17:47, Jilles Tjoelker wrote:
>
> > The code which does that check is actually under contrib/gcc. Problem
> > is, they designed __gthread_active_p() to distinguish threaded and
> > unthreaded programming environments
On 14 Jan 2013, at 17:47, Jilles Tjoelker wrote:
> The code which does that check is actually under contrib/gcc. Problem
> is, they designed __gthread_active_p() to distinguish threaded and
> unthreaded programming environments -- it must be known in advance and
> cannot be changed later. The code
On Mon, Jan 14, 2013 at 11:06:07AM -0500, John Baldwin wrote:
> On Saturday, January 12, 2013 11:25:47 am Jilles Tjoelker wrote:
> > With that, I think fast sigblock is too much code and complication
> > for a niche case.
> It does seem a bit complicated to me as well.
> > Most of the extra atomi
On Monday, January 14, 2013 11:50:03 am Alfred Perlstein wrote:
> On 1/14/13 11:06 AM, John Baldwin wrote:
> > On Saturday, January 12, 2013 11:25:47 am Jilles Tjoelker wrote:
> >> With that, I think fast sigblock is too much code and complication for a
> >> niche case.
> > It does seem a bit compl
On 1/14/13 11:06 AM, John Baldwin wrote:
On Saturday, January 12, 2013 11:25:47 am Jilles Tjoelker wrote:
With that, I think fast sigblock is too much code and complication for a
niche case.
It does seem a bit complicated to me as well.
Most of the extra atomics in multi-threaded applications
On Saturday, January 12, 2013 11:25:47 am Jilles Tjoelker wrote:
> With that, I think fast sigblock is too much code and complication for a
> niche case.
It does seem a bit complicated to me as well.
> Most of the extra atomics in multi-threaded applications are conditional
> on __isthreaded (or
On Sun, 2013-01-13 at 19:50 +0200, Konstantin Belousov wrote:
> On Sun, Jan 13, 2013 at 10:46:27AM -0700, Ian Lepore wrote:
> > On Sun, 2013-01-13 at 17:06 +0200, Konstantin Belousov wrote:
> > > On Sun, Jan 13, 2013 at 07:50:14AM -0700, Ian Lepore wrote:
> > > > On Sat, 2013-01-12 at 15:04 -0800,
On Sun, Jan 13, 2013 at 10:46:27AM -0700, Ian Lepore wrote:
> On Sun, 2013-01-13 at 17:06 +0200, Konstantin Belousov wrote:
> > On Sun, Jan 13, 2013 at 07:50:14AM -0700, Ian Lepore wrote:
> > > On Sat, 2013-01-12 at 15:04 -0800, John-Mark Gurney wrote:
> > > > David Xu wrote this message on Tue, Ja
On Sun, 2013-01-13 at 17:06 +0200, Konstantin Belousov wrote:
> On Sun, Jan 13, 2013 at 07:50:14AM -0700, Ian Lepore wrote:
> > On Sat, 2013-01-12 at 15:04 -0800, John-Mark Gurney wrote:
> > > David Xu wrote this message on Tue, Jan 08, 2013 at 13:09 +0800:
> > > > and can not be freed until proces
On Sun, Jan 13, 2013 at 07:50:14AM -0700, Ian Lepore wrote:
> On Sat, 2013-01-12 at 15:04 -0800, John-Mark Gurney wrote:
> > David Xu wrote this message on Tue, Jan 08, 2013 at 13:09 +0800:
> > > and can not be freed until process is exited, the page is doubly
> > > mapped into in kernel and userla
On Sat, 2013-01-12 at 15:04 -0800, John-Mark Gurney wrote:
> David Xu wrote this message on Tue, Jan 08, 2013 at 13:09 +0800:
> > and can not be freed until process is exited, the page is doubly
> > mapped into in kernel and userland, accessing the shared data
> > in kernel has zero overhead though
On Sun, Jan 13, 2013 at 02:32:00PM +0100, Jilles Tjoelker wrote:
> On Sat, Jan 12, 2013 at 05:25:47PM +0100, Jilles Tjoelker wrote:
> > This suggests a different rather simpler change. Libthr can always use
> > its rtld lock implementation instead of only when multiple threads
> > exist. This avoid
On Sat, Jan 12, 2013 at 05:25:47PM +0100, Jilles Tjoelker wrote:
> This suggests a different rather simpler change. Libthr can always use
> its rtld lock implementation instead of only when multiple threads
> exist. This avoids the sigprocmask() syscalls and should not be much
> slower than the def
David Xu wrote this message on Tue, Jan 08, 2013 at 13:09 +0800:
> and can not be freed until process is exited, the page is doubly
> mapped into in kernel and userland, accessing the shared data
> in kernel has zero overhead though.
Don't forget that there are arches out there w/ VIVT caches whic
On Sat, Jan 12, 2013 at 05:25:47PM +0100, Jilles Tjoelker wrote:
> On Sat, Jan 12, 2013 at 07:31:48AM +0200, Konstantin Belousov wrote:
> > On Sat, Jan 12, 2013 at 12:29:06AM +0100, Jilles Tjoelker wrote:
> > > On Fri, Jan 11, 2013 at 10:49:38PM +0200, Konstantin Belousov wrote:
> > > > http://peop
On 1/11/13 9:31 PM, Konstantin Belousov wrote:
On Sat, Jan 12, 2013 at 12:29:06AM +0100, Jilles Tjoelker wrote:
On Fri, Jan 11, 2013 at 10:49:38PM +0200, Konstantin Belousov wrote:
http://people.freebsd.org/~kib/misc/rtld-sigblock.3.patch
The new fields td_sigblock_ptr and td_sigblock_val are
On Sat, Jan 12, 2013 at 07:31:48AM +0200, Konstantin Belousov wrote:
> On Sat, Jan 12, 2013 at 12:29:06AM +0100, Jilles Tjoelker wrote:
> > On Fri, Jan 11, 2013 at 10:49:38PM +0200, Konstantin Belousov wrote:
> > > http://people.freebsd.org/~kib/misc/rtld-sigblock.3.patch
> > The new fields td_sig
On Sat, Jan 12, 2013 at 08:27:06AM +0800, David Xu wrote:
> On 2013/01/12 07:29, Jilles Tjoelker wrote:
> > On Fri, Jan 11, 2013 at 10:49:38PM +0200, Konstantin Belousov wrote:
> >> http://people.freebsd.org/~kib/misc/rtld-sigblock.3.patch
> > The new fields td_sigblock_ptr and td_sigblock_val are
On Sat, Jan 12, 2013 at 12:29:06AM +0100, Jilles Tjoelker wrote:
> On Fri, Jan 11, 2013 at 10:49:38PM +0200, Konstantin Belousov wrote:
> > http://people.freebsd.org/~kib/misc/rtld-sigblock.3.patch
>
> The new fields td_sigblock_ptr and td_sigblock_val are in the part that
> is zeroed for new thre
On 2013/01/12 07:29, Jilles Tjoelker wrote:
> On Fri, Jan 11, 2013 at 10:49:38PM +0200, Konstantin Belousov wrote:
>> http://people.freebsd.org/~kib/misc/rtld-sigblock.3.patch
> The new fields td_sigblock_ptr and td_sigblock_val are in the part that
> is zeroed for new threads, while the code in rt
On Fri, Jan 11, 2013 at 10:49:38PM +0200, Konstantin Belousov wrote:
> http://people.freebsd.org/~kib/misc/rtld-sigblock.3.patch
The new fields td_sigblock_ptr and td_sigblock_val are in the part that
is zeroed for new threads, while the code in rtld appears to expect them
to be copied (on fork, v
On Sat, Jan 12, 2013 at 12:51:56AM +0400, Lev Serebryakov wrote:
> Hello, Konstantin.
> You wrote 11 января 2013 г., 13:54:59:
>
>
> KB> http://people.freebsd.org/~kib/misc/rtld-sigblock.2.patch
> KB> is the commit candidate. Now kernel informs rtld about supprt for
> Is it first patch in t
Hello, Konstantin.
You wrote 11 января 2013 г., 13:54:59:
KB> http://people.freebsd.org/~kib/misc/rtld-sigblock.2.patch
KB> is the commit candidate. Now kernel informs rtld about supprt for
Is it first patch in this state, which implements idea of shared
memory between kernel and userland
On Fri, Jan 11, 2013 at 06:23:44PM +0800, David Xu wrote:
> On 2013/01/11 17:54, Konstantin Belousov wrote:
> > On Mon, Jan 07, 2013 at 08:22:35PM +0200, Konstantin Belousov wrote:
> >> Below is the forward of the patch for which I failed to obtain a private
> >> review. Might be, the list generate
On 2013/01/11 17:54, Konstantin Belousov wrote:
On Mon, Jan 07, 2013 at 08:22:35PM +0200, Konstantin Belousov wrote:
Below is the forward of the patch for which I failed to obtain a private
review. Might be, the list generates more responses.
Our rtld has a performance bootleneck, typically exp
On Mon, Jan 07, 2013 at 08:22:35PM +0200, Konstantin Belousov wrote:
> Below is the forward of the patch for which I failed to obtain a private
> review. Might be, the list generates more responses.
>
> Our rtld has a performance bootleneck, typically exposed by the images
> with the lot of the ru
On 1/9/13 2:38 AM, Konstantin Belousov wrote:
On Tue, Jan 08, 2013 at 10:02:22AM -0500, Alfred Perlstein wrote:
I think it would be great if it works, I just haven't had time to fully
understand your more recent patch. If you feel it's safe and maybe do a
few test programs to see what happens,
On Tue, Jan 08, 2013 at 10:02:22AM -0500, Alfred Perlstein wrote:
> I think it would be great if it works, I just haven't had time to fully
> understand your more recent patch. If you feel it's safe and maybe do a
> few test programs to see what happens, that would be best.
I revived the test p
On 1/8/13 9:56 AM, Konstantin Belousov wrote:
On Tue, Jan 08, 2013 at 01:09:51PM +0800, David Xu wrote:
On 2013/01/08 02:22, Konstantin Belousov wrote:
Below is the forward of the patch for which I failed to obtain a private
review. Might be, the list generates more responses.
Our rtld has a p
On Tue, Jan 08, 2013 at 01:21:48AM -0500, Alfred Perlstein wrote:
> On 1/7/13 7:08 PM, Konstantin Belousov wrote:
> > On Mon, Jan 07, 2013 at 03:42:01PM -0500, Alfred Perlstein wrote:
> >> On 1/7/13 1:22 PM, Konstantin Belousov wrote:
> >>> Below is the forward of the patch for which I failed to ob
On Tue, Jan 08, 2013 at 01:09:51PM +0800, David Xu wrote:
> On 2013/01/08 02:22, Konstantin Belousov wrote:
> > Below is the forward of the patch for which I failed to obtain a private
> > review. Might be, the list generates more responses.
> >
> > Our rtld has a performance bootleneck, typically
On 1/7/13 7:08 PM, Konstantin Belousov wrote:
On Mon, Jan 07, 2013 at 03:42:01PM -0500, Alfred Perlstein wrote:
On 1/7/13 1:22 PM, Konstantin Belousov wrote:
Below is the forward of the patch for which I failed to obtain a private
review. Might be, the list generates more responses.
Very cool.
On 2013/01/08 02:22, Konstantin Belousov wrote:
Below is the forward of the patch for which I failed to obtain a private
review. Might be, the list generates more responses.
Our rtld has a performance bootleneck, typically exposed by the images
with the lot of the run-time relocation processing,
On Mon, Jan 07, 2013 at 03:42:01PM -0500, Alfred Perlstein wrote:
> On 1/7/13 1:22 PM, Konstantin Belousov wrote:
> > Below is the forward of the patch for which I failed to obtain a private
> > review. Might be, the list generates more responses.
> Very cool.
>
> Sorry for being rusty here, but i
On 1/7/13 1:22 PM, Konstantin Belousov wrote:
Below is the forward of the patch for which I failed to obtain a private
review. Might be, the list generates more responses.
Very cool.
Sorry for being rusty here, but is it safe to call fuword in the middle
of issignal()?
The reason I ask is be
On Mon, Jan 07, 2013 at 12:18:41PM -0800, Julian Elischer wrote:
> On 1/7/13 10:22 AM, Konstantin Belousov wrote:
> > Below is the forward of the patch for which I failed to obtain a private
> > review. Might be, the list generates more responses.
> >
> > Our rtld has a performance bootleneck, typi
On 1/7/13 10:22 AM, Konstantin Belousov wrote:
Below is the forward of the patch for which I failed to obtain a private
review. Might be, the list generates more responses.
Our rtld has a performance bootleneck, typically exposed by the images
with the lot of the run-time relocation processing,
Below is the forward of the patch for which I failed to obtain a private
review. Might be, the list generates more responses.
Our rtld has a performance bootleneck, typically exposed by the images
with the lot of the run-time relocation processing, and by the C++
exception handling. We block the s
41 matches
Mail list logo
