Thanks, I'll use your list as a starting point. One question though:
On Wed Nov 24 2010 at 00:16:37 +, Andrew Doran wrote:
- build.sh on a static, unchanging source tree.
From the SSP discussion I have a recollection that build.sh can be
very jittery, up to the order of 1% per build. I've
On Wed Nov 24 2010 at 12:42:44 -0500, Thor Lancelot Simon wrote:
On Wed, Nov 24, 2010 at 04:52:38PM +0200, Antti Kantee wrote:
Thanks, I'll use your list as a starting point. One question though:
On Wed Nov 24 2010 at 00:16:37 +, Andrew Doran wrote:
- build.sh on a static,
On Tue, Nov 23, 2010 at 06:49:47PM +0200, Antti Kantee wrote:
On Fri Nov 19 2010 at 00:11:12 +, Andrew Doran wrote:
You can release it with either call, mutex_spin_ is just a way to avoid
additional atomic operations. The ususal case is adaptive mutex, but
stuff like the
On Fri Nov 19 2010 at 00:11:12 +, Andrew Doran wrote:
You can release it with either call, mutex_spin_ is just a way to avoid
additional atomic operations. The ususal case is adaptive mutex, but
stuff like the dispatcher/scheduler makes use of spin mutexes exclusively
and the fast path
On Tue, Nov 23, 2010 at 06:49:47PM +0200, Antti Kantee wrote:
On Fri Nov 19 2010 at 00:11:12 +, Andrew Doran wrote:
You can release it with either call, mutex_spin_ is just a way to avoid
additional atomic operations. The ususal case is adaptive mutex, but
stuff like the
On 11/19/10 01:50, Johnny Billquist wrote:
mutex exit spin with unlock appears to totally have been because some
spin locks were managed to be taken though mutex_vector_enter, even
though I have a mutex_spin_enter. I have no idea how on earth that path
would be possible, but after changing the
On Fri, Nov 19, 2010 at 01:04:50PM +0100, Johnny Billquist wrote:
Doh! Stupid of me. I just realized how mutexes can be taken without ever
passing through mutex_enter or mutex_vector_enter, even if they are
defined. We also have mutex_tryenter, which cannot be redefined.
So make it so it
On Nov,Friday 19 2010, at 1:04 PM, Johnny Billquist wrote:
On 11/19/10 01:50, Johnny Billquist wrote:
mutex exit spin with unlock appears to totally have been because some
spin locks were managed to be taken though mutex_vector_enter, even
though I have a mutex_spin_enter. I have no idea how
Johnny Billquist wrote:
What I don't get is why it take so much time to even respond to
pings, compared to Ultrix or VMS. What are we doing in the kernel??? As
usual, I'm open to suggestions...
Have you tried a profiling kernel? I know that can introduce its own overheads,
but might point
Johnny Billquist wrote:
On 2010-11-20 03:59, Simon Burge wrote:
Johnny Billquist wrote:
What I don't get is why it take so much time to even respond to
pings, compared to Ultrix or VMS. What are we doing in the kernel??? As
usual, I'm open to suggestions...
Have you tried a
On 2010-11-19 01:13, Andrew Doran wrote:
On Wed, Nov 17, 2010 at 12:30:59PM +0100, Johnny Billquist wrote:
On 11/17/10 11:38, Johnny Billquist wrote:
On 11/17/10 05:15, Matt Thomas wrote:
On Nov 16, 2010, at 8:04 PM, Johnny Billquist wrote:
On 2010-11-17 04:52, Matt Thomas wrote:
Not
On 2010-11-19 01:16, Andrew Doran wrote:
On Wed, Nov 17, 2010 at 03:03:20PM +1100, matthew green wrote:
- hppa seems to have a mutex implemented without cas. is it broken?
FWIW, the sparc implementation is only broken on SMP.
My recollection is that there were problems with the assembly
On 11/17/10 05:15, Matt Thomas wrote:
On Nov 16, 2010, at 8:04 PM, Johnny Billquist wrote:
On 2010-11-17 04:52, Matt Thomas wrote:
Not true. Spinlocks must enter through mutex_spin_enter and adaptive mutexes
enter through mutex_enter. The corresponding is true for exiting as well.
The
On 11/17/10 11:38, Johnny Billquist wrote:
On 11/17/10 05:15, Matt Thomas wrote:
On Nov 16, 2010, at 8:04 PM, Johnny Billquist wrote:
On 2010-11-17 04:52, Matt Thomas wrote:
Not true. Spinlocks must enter through mutex_spin_enter and adaptive
mutexes
enter through mutex_enter. The
On Wed, Nov 17, 2010 at 11:38:54AM +0100, Johnny Billquist wrote:
Ouch. Should I also file bugs for mutexes that are released, but
already appear to be free?
Yes.
Because that also happens.
LOCKDEBUG should detect this, I guess.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans
On 11/17/10 13:55, Thor Lancelot Simon wrote:
On Wed, Nov 17, 2010 at 01:31:51PM +0100, Johnny Billquist wrote:
But you could perhaps argue that this is a bug in itself, and
mutex_vector_enter should not take a spin mutex on its own when a
mutex_spin_enter function exist.
I don't think
On Wed, Nov 17, 2010 at 07:55:13AM -0500, Thor Lancelot Simon wrote:
On Wed, Nov 17, 2010 at 01:31:51PM +0100, Johnny Billquist wrote:
But you could perhaps argue that this is a bug in itself, and
mutex_vector_enter should not take a spin mutex on its own when a
mutex_spin_enter
On 11/17/10 14:34, Andrew Doran wrote:
On Wed, Nov 17, 2010 at 07:55:13AM -0500, Thor Lancelot Simon wrote:
On Wed, Nov 17, 2010 at 01:31:51PM +0100, Johnny Billquist wrote:
But you could perhaps argue that this is a bug in itself, and
mutex_vector_enter should not take a spin mutex on its
On 11/17/10 05:03, matthew green wrote:
- hppa seems to have a mutex implemented without cas. is it broken?
FWIW, the sparc implementation is only broken on SMP.
Did they use their own mutex_enter and mutex_spin_enter? If so, it might
be that the fact that mutex_vector_enter has it's own
Please could somebody on the eat your CAS whether you like it or not
side of the fence explain why the following idea would not work:
On Sat, 13 Nov 2010, der Mouse wrote:
Consider this hypothetical:
x86 does #define ATOMIC_OPS_USE_CAS and defines a CAS(); MI code
notices this and defines
On Tue, Nov 16, 2010 at 09:44:18AM -0800, Matt Thomas wrote:
On Nov 16, 2010, at 9:10 AM, Alan Barrett wrote:
Please could somebody on the eat your CAS whether you like it or not
side of the fence explain why the following idea would not work:
On Sat, 13 Nov 2010, der Mouse wrote:
On 2010-11-16 18:44, Matt Thomas wrote:
On Nov 16, 2010, at 9:10 AM, Alan Barrett wrote:
Please could somebody on the eat your CAS whether you like it or not
side of the fence explain why the following idea would not work:
On Sat, 13 Nov 2010, der Mouse wrote:
Consider this hypothetical:
On 2010-11-16 19:32, Eric Haszlakiewicz wrote:
On Tue, Nov 16, 2010 at 09:44:18AM -0800, Matt Thomas wrote:
On Nov 16, 2010, at 9:10 AM, Alan Barrett wrote:
Please could somebody on the eat your CAS whether you like it or not
side of the fence explain why the following idea would not work:
On
hi,
On 2010-11-16 19:32, Eric Haszlakiewicz wrote:
On Tue, Nov 16, 2010 at 09:44:18AM -0800, Matt Thomas wrote:
On Nov 16, 2010, at 9:10 AM, Alan Barrett wrote:
Please could somebody on the eat your CAS whether you like it or not
side of the fence explain why the following idea would not
FWIW, there *are* sparc implementations of the mutex vector
functions, but we had to disable them because of lossage we
we not able to (yet) track down. they mostly work, so may
be useful for at least reading.
.mrg.
On Nov 16, 2010, at 7:32 PM, Johnny Billquist wrote:
On 2010-11-17 04:25, matthew green wrote:
The (my) problem is that rwlocks must use CAS as well, and I'm starting
to think that I have to use CAS for the mutex code as well, as I can't
seem to get mutexs work reliably without using the
- hppa seems to have a mutex implemented without cas. is it broken?
FWIW, the sparc implementation is only broken on SMP.
.mrg.
On Nov 16, 2010, at 8:04 PM, Johnny Billquist wrote:
On 2010-11-17 04:52, Matt Thomas wrote:
Not true. Spinlocks must enter through mutex_spin_enter and adaptive mutexes
enter through mutex_enter. The corresponding is true for exiting as well.
The only reason mutex_vector_{enter,exit} is
On 11/14/10 20:16, David Holland wrote:
On Sat, Nov 13, 2010 at 01:45:40AM +0900, Izumi Tsutsui wrote:
Wow. I guess you can add me to the list of people leaving.
There is no perfect world and we don't have enough resources.
Any help to keep support for ancient machines are
On 11/15/10 14:55, Johnny Billquist wrote:
On 11/14/10 20:16, David Holland wrote:
On Sat, Nov 13, 2010 at 01:45:40AM +0900, Izumi Tsutsui wrote:
Wow. I guess you can add me to the list of people leaving.
There is no perfect world and we don't have enough resources.
Any help to keep
On Fri, Nov 12, 2010 at 02:21:34PM +0100, Johnny Billquist wrote:
then I realized that this solution would break if people actually
wrote code like
lock(a)
lock(b)
release(a)
release(b)
...which is very common.
It is? I would have thought (and hoped)
Just a note to avoid having incorrect information in the archives
without a correction. I wrote:
[%] It occurs to me, the VAX's BBSSI and BBCCI _are_ CAS, just
restricted to a one-bit-wide operand (and with the data-to-swap-in
specified by choice of instruction rather than an operand).
This
On Sat, Nov 13, 2010 at 01:45:40AM +0900, Izumi Tsutsui wrote:
Wow. I guess you can add me to the list of people leaving.
There is no perfect world and we don't have enough resources.
Any help to keep support for ancient machines are appreciate, but
complaints like we should support
Hadn't it been much nicer of we just had the mutex and lock
abstraction, and left the whole implementation to each MD part?
Exactly. Consider this hypothetical:
x86 does #define ATOMIC_OPS_USE_CAS and defines a CAS(); MI code
notices this and defines all the higher-level primitives (if that's
Already wrote about reasoning in other reply to mouse (keywords: no
code duplication, better design), so wont repeat myself.
Except you appear to think that the only options are the current state
and each arch totally doing its own thing.
There are places other than those two to draw the
On Fri, Nov 12, 2010 at 11:09:20AM +, Andrew Doran wrote:
On Thu, Nov 11, 2010 at 05:22:03PM +0100, Johnny Billquist wrote:
The mutex implementation in place now, is nice in many ways, as it
is rather open to different implementations based on what the
hardware can do. However, I
On Fri, Nov 12, 2010 at 11:09:20AM +, Andrew Doran wrote:
It was deliberate. rwlocks are only effective in situations where the
codepath is heavyweight. So I felt while it is worthwhile optimising them
if possible, an all out jihad is just not warranted (as it might be for
mutexes). So
On Thu, Nov 11, 2010 at 06:35:55PM +0100, Johnny Billquist wrote:
Hmm. Hard to argue about this. While I think it's nice if we try to
keep the kernel agnostic, the user api is not something I'm arguing
about changing. But it would be nice if we could leave it possible
to do things in different
On Fri, Nov 12, 2010 at 01:56:20PM +0100, Joerg Sonnenberger wrote:
On Thu, Nov 11, 2010 at 06:35:55PM +0100, Johnny Billquist wrote:
Hmm. Hard to argue about this. While I think it's nice if we try to
keep the kernel agnostic, the user api is not something I'm arguing
about changing. But
On 11/12/10 03:58, David Holland wrote:
On Thu, Nov 11, 2010 at 06:35:55PM +0100, Johnny Billquist wrote:
[spl mutex stuff]
Hum? So that was introduced with the new locking code then? Because
back when we used splraise/splx, the above would not have worked.
This would have
On 11/12/10 12:16, Andrew Doran wrote:
On Fri, Nov 12, 2010 at 11:09:20AM +, Andrew Doran wrote:
It was deliberate. rwlocks are only effective in situations where the
codepath is heavyweight. So I felt while it is worthwhile optimising them
if possible, an all out jihad is just not
On 11/12/10 13:56, Joerg Sonnenberger wrote:
On Thu, Nov 11, 2010 at 06:35:55PM +0100, Johnny Billquist wrote:
Hmm. Hard to argue about this. While I think it's nice if we try to
keep the kernel agnostic, the user api is not something I'm arguing
about changing. But it would be nice if we could
On 11/12/10 15:00, Johnny Billquist wrote:
On 11/12/10 14:55, Joerg Sonnenberger wrote:
On Fri, Nov 12, 2010 at 02:35:59PM +0100, Johnny Billquist wrote:
Augh! And in which way would that improve things? Restarting
operations, as well as checking if they should be restarted will
hardly be
On Fri, Nov 12, 2010 at 02:58:16PM +0100, Johnny Billquist wrote:
lock(interlock)
lock(a)
lock(b)
unlock(interlock)
I realized I'm getting sloppy here. When I say locks in this
context, I'm actually talking about spin mutexes. Simple locks are a
different story, since they don't fool with
On 11/12/10 15:07, Joerg Sonnenberger wrote:
On Fri, Nov 12, 2010 at 02:58:16PM +0100, Johnny Billquist wrote:
lock(interlock)
lock(a)
lock(b)
unlock(interlock)
I realized I'm getting sloppy here. When I say locks in this
context, I'm actually talking about spin mutexes. Simple locks are a
On Fri Nov 12 2010 at 14:30:58 +0100, Johnny Billquist wrote:
By reasoning that we should design for tomorrows hardware, we might as
well design explicitly for x86_64, and let all other emulate that. But
in the past, I believe NetBSD have tried to raise above such simple and
naïve
On 11/12/10 15:22, Antti Kantee wrote:
On Fri Nov 12 2010 at 14:30:58 +0100, Johnny Billquist wrote:
By reasoning that we should design for tomorrows hardware, we might as
well design explicitly for x86_64, and let all other emulate that. But
in the past, I believe NetBSD have tried to raise
On Fri, Nov 12, 2010 at 03:25:04PM +0100, Johnny Billquist wrote:
So what you are arguing is that MI needn't be so much MI anymore,
and that supporting anything more than mainstream today is more to
be considered a lucky accident than a desired goal?
It is not about mainstream. Please tell me
On Fri, Nov 12, 2010 at 02:30:58PM +0100, Johnny Billquist wrote:
Hmm. The thing with rwlocks though is that the actual concept is
just that you have locks that you want to grab, with the expanded
idea that you can have them at two different levels. read or write.
There is nothing inherently
It is not about mainstream. Please tell me one architecture that has
been created in the last 10 years, supports at least 32bit address
space, virtual memory and doesn't support either CAS or LL/SC.
What's that got to do with it?
NetBSD used to be about proper separation between MI and MD so
On Fri, Nov 12, 2010 at 09:50:52AM -0500, der Mouse wrote:
Over 15 years ago NetBSD had a possibility to take everyone into
account [...]
So what you are arguing is that MI needn't be so much MI anymore, and
that supporting anything more than mainstream today is more to be
considered a
On 11/12/10 15:52, Andrew Doran wrote:
On Fri, Nov 12, 2010 at 02:30:58PM +0100, Johnny Billquist wrote:
Hmm. The thing with rwlocks though is that the actual concept is
just that you have locks that you want to grab, with the expanded
idea that you can have them at two different levels. read
On Nov 12, 2010, at 6:39 AM, Joerg Sonnenberger wrote:
On Fri, Nov 12, 2010 at 03:25:04PM +0100, Johnny Billquist wrote:
So what you are arguing is that MI needn't be so much MI anymore,
and that supporting anything more than mainstream today is more to
be considered a lucky accident than a
Ooo. Really friendly here. Yes, excellent idea. Drive people away. That
will surely help. Please remind me again, why would people in general
want to run NetBSD instead of Linux or FreeBSD?
It's good thing to keep support for old machines with MI API.
It's bad thing to complain about
On Sat, 13 Nov 2010, Izumi Tsutsui wrote:
Oh well! I guess I should go away now.
And me, and everyone else running anything but x86_64 (and, maybe,
i386; I don't know whether that's sufficiently modern to count).
Yes, please go.
Wow. I guess you can add me to the list of people leaving.
On 11/12/10 16:38, Izumi Tsutsui wrote:
Ooo. Really friendly here. Yes, excellent idea. Drive people away. That
will surely help. Please remind me again, why would people in general
want to run NetBSD instead of Linux or FreeBSD?
It's good thing to keep support for old machines with MI API.
On 11/12/10 15:56, Andrew Doran wrote:
On Fri, Nov 12, 2010 at 09:50:52AM -0500, der Mouse wrote:
Over 15 years ago NetBSD had a possibility to take everyone into
account [...]
So what you are arguing is that MI needn't be so much MI anymore, and
that supporting anything more than mainstream
Andrew Doran a...@homeworld.netbsd.org wrote:
bqt, wanna start a fork? Looks as though NetBSD no longer supports
most of the architectures it used to.
That idea could have merit.
Indeed..
--
Mindaugas
On 11/12/10 16:12, Izumi Tsutsui wrote:
Oh well! I guess I should go away now.
And me, and everyone else running anything but x86_64 (and, maybe,
i386; I don't know whether that's sufficiently modern to count).
Yes, please go.
Ooo. Really friendly here. Yes, excellent idea. Drive people
On 11/12/10 16:23, Izumi Tsutsui wrote:
Ooo. Really friendly here. Yes, excellent idea. Drive people away. That
will surely help. Please remind me again, why would people in general
want to run NetBSD instead of Linux or FreeBSD?
It's good thing to keep support for old machines with MI API.
* On 2010-11-12 at 16:26 GMT, Johnny Billquist wrote:
What? That NetBSD no longer supports most of the architectures it used to?
Unless you've redefined the meaning of 'most' I think that's a pretty
wild and inaccurate claim.
Maybe it's time to change the of course it runs NetBSD to is it
an
On Nov 12, 2010, at 7:08 AM, Johnny Billquist wrote:
On 11/12/10 15:56, Andrew Doran wrote:
On Fri, Nov 12, 2010 at 09:50:52AM -0500, der Mouse wrote:
Over 15 years ago NetBSD had a possibility to take everyone into
account [...]
So what you are arguing is that MI needn't be so much MI
Antti Kantee po...@cs.hut.fi wrote:
On Fri Nov 12 2010 at 14:30:58 +0100, Johnny Billquist wrote:
By reasoning that we should design for tomorrows hardware, we might as
well design explicitly for x86_64, and let all other emulate that. But
in the past, I believe NetBSD have tried to raise
On Fri Nov 12 2010 at 15:25:04 +0100, Johnny Billquist wrote:
Freeway design is not driven by the requirements of the horse. If a horse
occasionally wants to gallop down a freeway, we're happy to let it as long
as it doesn't cause any impediment to the actual users of the freeway.
Over 15
Exactly! And I would like to emphasize that this has nothing to do
with breaking of MI and MD abstraction or x86-centric view.
Yes, I imagine you would. But it's still false.
Decision was to provide CAS abstraction [sic!] as a primitive for MI,
by the MD land - in a same way, like we have
On Fri Nov 12 2010 at 16:58:18 +, Mindaugas Rasiukevicius wrote:
What Johnny apparently suggests is to revisit mutex(9) interface, which
is known to work very well, and optimise it for VAX. Well, I hope we
do not design MI code to be focused on VAX. If we do, then perhaps I
picked the
On Nov 12, 2010, at 9:24 AM, David Young wrote:
On Thu, Nov 11, 2010 at 05:22:03PM +0100, Johnny Billquist wrote:
*snip snip*
All others rely on the __HAVE_SIMPLE_MUTEXES
implementation, which utilize a CAS function. Obviously the VAX does
not have a CAS, and it is rather costly to simulate
Yes. NetBSD is the only option for some of us (non-new processors) and
now you're trying to make it rotten for us.
It's a choice which we should focus on. No perfect world.
Wouldn't it make more sense with your limited resources to contribute to
something more mainstream-focused like
der Mouse mo...@rodents-montreal.org wrote:
Decision was to provide CAS abstraction [sic!] as a primitive for MI,
by the MD land - in a same way, like we have copy(9), fetch(9),
store(9) or many other means, just in this case MI asks MD to ensure
atomicity. It was relevant to make a
On Fri, Nov 12, 2010 at 03:39:07PM +0100, Joerg Sonnenberger wrote:
It is not about mainstream. Please tell me one architecture that has
been created in the last 10 years, supports at least 32bit address
space, virtual memory and doesn't support either CAS or LL/SC. I would
be very surprised
On Thu, Nov 11, 2010 at 06:35:55PM +0100, Johnny Billquist wrote:
this solution would break if people actually wrote code like
lock(a)
lock(b)
release(a)
release(b)
That sequence is important, lock 'a' might control the global table, and
lock 'b' a specific entry. Otherwise you have to
On 2010-11-12 17:48, Jonathan Perkin wrote:
* On 2010-11-12 at 16:26 GMT, Johnny Billquist wrote:
What? That NetBSD no longer supports most of the architectures it used to?
Unless you've redefined the meaning of 'most' I think that's a pretty
wild and inaccurate claim.
Please try and keep
On 2010-11-12 17:58, Mindaugas Rasiukevicius wrote:
Antti Kanteepo...@cs.hut.fi wrote:
On Fri Nov 12 2010 at 14:30:58 +0100, Johnny Billquist wrote:
By reasoning that we should design for tomorrows hardware, we might as
well design explicitly for x86_64, and let all other emulate that. But
in
On 2010-11-12 18:19, Antti Kantee wrote:
On Fri Nov 12 2010 at 16:58:18 +, Mindaugas Rasiukevicius wrote:
What Johnny apparently suggests is to revisit mutex(9) interface, which
is known to work very well, and optimise it for VAX. Well, I hope we
do not design MI code to be focused on VAX.
On Sat, 13 Nov 2010, Izumi Tsutsui wrote:
Wow. I guess you can add me to the list of people leaving.
There is no perfect world and we don't have enough resources.
Any help to keep support for ancient machines are appreciate, but
complaints like we should support it which prevents
On 2010-11-13 00:48, Mindaugas Rasiukevicius wrote:
Johnny Billquistb...@softjar.se wrote:
Exactly! And I would like to emphasize that this has nothing to do with
breaking of MI and MD abstraction or x86-centric view. Decision was to
provide CAS abstraction [sic!] as a primitive for MI, by
On Thu, 11 Nov 2010 17:22:03 +0100
Johnny Billquist b...@softjar.se wrote:
I've been looking through the netbsd mutex, and lock implementations the
last few days, with the intent to try and improve the performance on the
VAX, which has suffered somewhat in performance with NetBSD (maybe
On 11/11/10 18:07, Mindaugas Rasiukevicius wrote:
Hello,
Similar questions were raised a few times.. let's go through this again.
Sorry if I am rehashing old stuff then...
Johnny Billquistb...@softjar.se wrote:
With mutex_spin, you instead store the original spl at the first
78 matches
Mail list logo
