Re: TSC vs. HPET timecounter priority

2012-08-12 Thread YAMAMOTO Takashi
hi, > On Sun, Aug 12, 2012 at 08:14:50PM -0700, Erik Fair wrote: > [..] > >> Until something is written and committed, I suggest an easy change in >> timecounter >> "quality" for HPET to make it preferred to TSC if both are present. > > It took me also a little while to recognize that i have a

Re: TSC vs. HPET timecounter priority

2012-08-12 Thread Bernd Ernesti
On Sun, Aug 12, 2012 at 08:14:50PM -0700, Erik Fair wrote: [..] > Until something is written and committed, I suggest an easy change in > timecounter > "quality" for HPET to make it preferred to TSC if both are present. It took me also a little while to recognize that i have a timecounter issue.

Re: [RFC][PATCH] _UC_TLSBASE for all ports

2012-08-12 Thread Emmanuel Dreyfus
YAMAMOTO Takashi wrote: > the current bahaviour would benefit applications which use i386 %gs register > for their own purposes. is it your concern? Note I did not propose to alter the default behavior. I just want an option to disable it. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@n

Re: [RFC][PATCH] _UC_TLSBASE for all ports

2012-08-12 Thread YAMAMOTO Takashi
hi, > On Fri, Aug 10, 2012 at 07:31:59PM +0200, Emmanuel Dreyfus wrote: >> Joerg Sonnenberger wrote: >> >> > I maintain that trying to move contexts between threads is an inherently >> > bad idea and that it is a very inefficient interface for implementing >> > coroutines. I object to this chang

TSC vs. HPET timecounter priority

2012-08-12 Thread Erik Fair
NetBSD has a problem with NTP time keeping on x86 systems which have TSC: if those systems have variable CPU clock frequency support for power consumption efficiency (e.g. SpeedStep, PowerNow), if or when the CPU frequency changes, the relationship between TSC and the ticking of real time change

Re: [RFC][PATCH] _UC_TLSBASE for all ports

2012-08-12 Thread Emmanuel Dreyfus
Joerg Sonnenberger wrote: > Or libpthread or rtld for the same kind of issue. I could understand libpthread would get confused if pthread_self() did not match struct lwp's l_lid, and this is just the problem I want to address by having _UC_TLSBASE on all ports. If you have the flag, you can disa

Re: [RFC][PATCH] _UC_TLSBASE for all ports

2012-08-12 Thread Joerg Sonnenberger
On Sun, Aug 12, 2012 at 07:27:36PM +0200, Emmanuel Dreyfus wrote: > rJoerg Sonnenberger wrote: > > > You are mixing up two unrelated items. The thread private area and the > > thread ID are not the same thing. Your "fix" only affects the former, > > not the latter. > > Right, I was not sure what

Re: [RFC][PATCH] _UC_TLSBASE for all ports

2012-08-12 Thread Emmanuel Dreyfus
rJoerg Sonnenberger wrote: > You are mixing up two unrelated items. The thread private area and the > thread ID are not the same thing. Your "fix" only affects the former, > not the latter. Right, I was not sure what you were talking about. You mean struct lwp's l_lid, right? If this is the case

Re: pinning down dk? assignment

2012-08-12 Thread Thomas Klausner
On Mon, Jul 23, 2012 at 04:21:55PM +0200, Martin Husemann wrote: > You can mount them by name. I have (on my non-GPT root disk): > > NAME=sb2k5Root/a/ ffs rw,log 1 1 > NAME=sb2k5Root/bnoneswapsw,dp0 0 > > in /etc/fstab. With gpt you can labe

Re: [RFC][PATCH] _UC_TLSBASE for all ports

2012-08-12 Thread Joerg Sonnenberger
On Sun, Aug 12, 2012 at 06:19:02PM +0200, Emmanuel Dreyfus wrote: > Joerg Sonnenberger wrote: > > > No, it doesn't. You don't change the lwpid if you move to a different > > kernel thread. As such, you are breaking the "lwpid is constant" > > property. > > This is how NetBSD currently behave, un

Re: [RFC][PATCH] _UC_TLSBASE for all ports

2012-08-12 Thread Emmanuel Dreyfus
Joerg Sonnenberger wrote: > No, it doesn't. You don't change the lwpid if you move to a different > kernel thread. As such, you are breaking the "lwpid is constant" > property. This is how NetBSD currently behave, unless the user takes care of unsetting _UC_TLSBASE before walling swapcontext().

[PATCH] _UC_TLSBASE, round 2

2012-08-12 Thread Emmanuel Dreyfus
Hi Attached is an updated patch for _UC_TLSBASE, with some documentation. I need help to validate the MD parts, especially for PowerPC. While we are there, it seems we could remove _UC_ARM_VFP (unused), and perhaps it would make sense to support _UC_SETSTACK and _UC_CLRSTACK on ports where it i

Re: [RFC][PATCH] _UC_TLSBASE for all ports

2012-08-12 Thread Emmanuel Dreyfus
Joerg Sonnenberger wrote: > They are still very heavy for coroutine usage. I cannot argue on that point. This is where it would be interesting if you could defend that on gluster-de...@nongnu.org. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org

Re: [RFC][PATCH] _UC_TLSBASE for all ports

2012-08-12 Thread Joerg Sonnenberger
On Sun, Aug 12, 2012 at 03:00:50AM +0200, Emmanuel Dreyfus wrote: > Joerg Sonnenberger wrote: > > > > Therefore I do not understand why you oppose the proposal of proposing a > > > MI interface to let the user opt out of that bad behavior. > > > > Your "fix" doesn't change this issue at all. >

Re: [RFC][PATCH] _UC_TLSBASE for all ports

2012-08-12 Thread Emmanuel Dreyfus
Joerg Sonnenberger wrote: > > Therefore I do not understand why you oppose the proposal of proposing a > > MI interface to let the user opt out of that bad behavior. > > Your "fix" doesn't change this issue at all. Of course it does. For now if you want to swapcontext() between threads, you c

Re: [RFC][PATCH] _UC_TLSBASE for all ports

2012-08-12 Thread Joerg Sonnenberger
On Sun, Aug 12, 2012 at 10:02:48AM +0200, Martin Husemann wrote: > - however, we should bring back (under slightly different names, and in libc) >the old pure userland setcontext (and friends) that we used to have >in the N:M libpthread. We have the code for all archs, it is tested, and >

Re: [RFC][PATCH] _UC_TLSBASE for all ports

2012-08-12 Thread Martin Husemann
So, I see various things coming together in this thread, and I would suggest to fix them all with a change beyound what Emmanuel originaly proposed: - the pthread_self() usage and the binding to a register is a property of our libpthread implementation, so it should overwrite setcontext and