Re: [RFC PATCH v4 1/4] libc: add more CPU_ macros

2016-11-30 Thread Justin Cinkelj
You are right, that one is not needed any more. I used CPU_AND to copy cpuset_t (dest = src & src; and only now noticed that memcpy is "recommend" way to copy it :). And since I was adding one, I added a few more of them. Description is from man CPU_SET, so glibc, yes. E.g. CPU_AND_S setsize is

[COMMIT osv master] libc: new thread should inherit parent thread cpu pinning

2016-11-30 Thread Commit Bot
From: Justin Cinkelj Committer: Nadav Har'El Branch: master libc: new thread should inherit parent thread cpu pinning Fixes #761 Signed-off-by: Justin Cinkelj Message-Id: <20161129141222.11595-3-justin.cink...@xlab.si> --- diff --git a/libc/pthread.cc b/libc/pthread.cc --- a/libc/pthread.cc

[COMMIT osv master] loader: start do_main_thread unpinned

2016-11-30 Thread Commit Bot
From: Justin Cinkelj Committer: Nadav Har'El Branch: master loader: start do_main_thread unpinned main_cont is pinned to CPU 0. The #761 asks for pthread_create to use caller thread CPU pinning for new thread (in case there is no explicit pinning requested with pthread_attr_t). Fix for #761 re

[COMMIT osv master] tests: new pthread should inherit parent CPU affinity

2016-11-30 Thread Commit Bot
From: Justin Cinkelj Committer: Nadav Har'El Branch: master tests: new pthread should inherit parent CPU affinity New pthread should have CPU affinity requested be cpuset in attributes. If explicit cpu pinning is not requested, than parent thread CPU pinning should be used. Signed-off-by: Jus

Re: [RFC PATCH v4 1/4] libc: add more CPU_ macros

2016-11-30 Thread Nadav Har'El
I've committed the three other patches in this series, but this one appears to be no longer needed. Did you want me to apply it anyway? Can you say a few words about why you wanted this specific functions and where you got their description? (are they inspired by what glibc have in sched.h?) --

Re: [Go runtime support v4 04/11] elf/app: Delay elf object initialization

2016-11-30 Thread Nadav Har'El
On Thu, Oct 27, 2016 at 3:06 PM, Benoît Canet < benoit.canet.cont...@gmail.com> wrote: > We want the init of the elf object to use > the tls defined when the new thread is started. > > Delay this initialization. > > Signed-off-by: Benoît Canet > --- > core/app.cc| 4 +++- > core/elf.cc

Re: Assert failure in sched::preemptable()

2016-11-30 Thread Nadav Har'El
On Wed, Nov 30, 2016 at 1:18 PM, Rick Payne wrote: > > > On 30 Nov 2016, at 07:07, Nadav Har'El wrote: > > > > I just sent to the mailing list a patch for this bug. Can you please try > it out? > > That works, thanks. > You're welcome, and thank you for the excellent detective work which uncove

Re: Assert failure in sched::preemptable()

2016-11-30 Thread Rick Payne
> On 30 Nov 2016, at 07:07, Nadav Har'El wrote: > > I just sent to the mailing list a patch for this bug. Can you please try it > out? That works, thanks. Rick -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this gro

[COMMIT osv master] pthread: pthread_spin_lock must not disabled preemption

2016-11-30 Thread Commit Bot
From: Nadav Har'El Committer: Nadav Har'El Branch: master pthread: pthread_spin_lock must not disabled preemption Our pthread_spin_lock implementation incorrectly used the kernel spinlock implementation which disabled preemption, which is both inappropriate and unnecessary for application code

Re: [PATCH] pthread: pthread_spin_lock must not disabled preemption

2016-11-30 Thread Avi Kivity
On 11/30/2016 01:05 PM, Nadav Har'El wrote: Our pthread_spin_lock implementation incorrectly used the kernel spinlock implementation which disabled preemption, which is both inappropriate and unnecessary for application code. Ironically, after commit 930cb83d914796893746d5d7f7f9cf6df37db5e6, p

Re: Assert failure in sched::preemptable()

2016-11-30 Thread Nadav Har'El
On Wed, Nov 30, 2016 at 11:52 AM, Nadav Har'El wrote: > Thanks. This is a real bug in pthread_spin_lock(). I opened > https://github.com/cloudius-systems/osv/issues/814 for this. > > I just sent to the mailing list a patch for this bug. Can you please try it out? Thanks, Nadav. -- You received

[PATCH] pthread: pthread_spin_lock must not disabled preemption

2016-11-30 Thread Nadav Har'El
Our pthread_spin_lock implementation incorrectly used the kernel spinlock implementation which disabled preemption, which is both inappropriate and unnecessary for application code. Ironically, after commit 930cb83d914796893746d5d7f7f9cf6df37db5e6, pthread_spin_lock() became completely unusable: A

Re: Assert failure in sched::preemptable()

2016-11-30 Thread Nadav Har'El
Thanks. This is a real bug in pthread_spin_lock(). I opened https://github.com/cloudius-systems/osv/issues/814 for this. -- Nadav Har'El n...@scylladb.com On Wed, Nov 30, 2016 at 3:21 AM, Rick Payne wrote: > > I kept track of previous calls to resolve_pltgot to see where the last > call was wh