Date:Mon, 25 Aug 2014 20:08:03 -0600
From:Sverre Froyen
Message-ID:
| Does the NetBSD version originate with BSD? The man pages for FreeBSD,
| OpenBSD and Mac OS X all have the same description.
Yes, and of course, as they all documented what the BSD implementat
On 2014-08-25, at 18:15, Robert Elz wrote:
>Date:Tue, 26 Aug 2014 08:04:11 +1000
>From:matthew green
>Message-ID: <29001.1409004...@splode.eterna.com.au>
>
> | Joerg Sonnenberger:
> | > memcmp is only supposed to provide the correct sign, not the difference.
> |
Date:Tue, 26 Aug 2014 08:04:11 +1000
From:matthew green
Message-ID: <29001.1409004...@splode.eterna.com.au>
| Joerg Sonnenberger:
| > memcmp is only supposed to provide the correct sign, not the difference.
|
| true, but that's not what memcmp(9) says.
This
Date: Mon, 25 Aug 2014 23:37:36 +0200
From: Joerg Sonnenberger
memcmp is only supposed to provide the correct sign, not the difference.
Our man page says difference, and has said that from the beginning.
> > Sounds reasonable to me, although it looks like GCC's old builtin
> > memcmp expansion actually failed to implement our specification: it
> > returns -1, 0, or +1, like your patch, rather than the difference of
> > the first differing bytes or zero as our man page specifies. For most
> > uses
On Mon, Aug 25, 2014 at 09:09:24PM +, Taylor R Campbell wrote:
>Date: Mon, 25 Aug 2014 20:02:44 +0200
>From: "J. Hannken-Illjes"
>
>Short answer: it is -- reverting external/gpl3/gcc/dist/gcc/builtins.c
>from Rev. 1.3 to 1.2 brings back the old times which are the same as
>
Date: Mon, 25 Aug 2014 20:02:44 +0200
From: "J. Hannken-Illjes"
Short answer: it is -- reverting external/gpl3/gcc/dist/gcc/builtins.c
from Rev. 1.3 to 1.2 brings back the old times which are the same as
they were on NetBSD 6.
Given that this test has many calls to ufs_lookup/c
Kengo NAKAHARA wrote:
> Sorry, I typo the patch URL.
>
> (2014/08/20 18:06), Kengo NAKAHARA wrote:
> > and here is the patch
> > http://knakahara.github.io/patches/netbsd/irq-affinity-initctl.patch
>
> http://knakahara.github.io/patches/netbsd/irq-affinity-intrctl.patch
Have to adm
Darren Reed wrote:
> Looking at the use of pserialze functions, you've got a single
> data structure (bpf_iflist) that is at some times covered by
> bpf_iflist_mtx and others not. That's a bad design. Ideally the
> data structure should only be covered by one locking mechanism
> so you need to cho
Ryota Ozaki wrote:
> Hi,
>
> I thought I need more experience of pserialize
> (and lock primitives) to tackle ifnet work.
> So I suspended the work and now I am trying
> another easier task, bpf.
>
> http://www.netbsd.org/~ozaki-r/mpsafe-bpf.diff
>
As Darren mentioned - there are various bugs
Ryota Ozaki wrote:
> > I generally agree with Dennis that is not the way we want to take in
> > the long-term. The cost of read-write lock is very high. The plan
> > is to use passive serialisation to protect the interfaces and their
> > addresses. Also, the ultimate goal would also be to use a
On 25 Aug 2014, at 15:55, J. Hannken-Illjes wrote:
> On 24 Aug 2014, at 18:57, J. Hannken-Illjes wrote:
>
>
>
>> I tried to bisect and got an increase in time from ~15 secs to ~24 secs
>> between the time stamps '2012-09-18 06:00 UTC' '2012-09-18 09:00 UTC'.
>>
>> Someone should redo this te
On 25 Aug 2014, at 17:39, Taylor R Campbell wrote:
> Date: Mon, 25 Aug 2014 15:55:53 +0200
> From: "J. Hannken-Illjes"
>
> GCC 4.5.4 disabled builtin memcmp as x86 has no cmpmemsi pattern.
>
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052, Comment 16.
>
> Could this be the
Date: Sun, 24 Aug 2014 15:26:46 +0200
From: Stephan
Okay maybe I should wait for dtrace to be enabled and working by default.
Well, plugh. Every one of the instructions I rattled off from memory
was slightly wrong, and apparently the default amd64 kernel doesn't
have enough KVA reserve
Date: Mon, 25 Aug 2014 15:55:53 +0200
From: "J. Hannken-Illjes"
GCC 4.5.4 disabled builtin memcmp as x86 has no cmpmemsi pattern.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052, Comment 16.
Could this be the cause of this big loss in performance?
Shouldn't be too hard to
On 24 Aug 2014, at 18:57, J. Hannken-Illjes wrote:
> I tried to bisect and got an increase in time from ~15 secs to ~24 secs
> between the time stamps '2012-09-18 06:00 UTC' '2012-09-18 09:00 UTC'.
>
> Someone should redo this test as this interval is the import of the
> compiler (GCC 4.5.3 ->
16 matches
Mail list logo
