Otto Moerbeek writes:
> What's the reason to move to RB trees? In general they are slower,
> have larger memory overhead
slower - not in practice. Especially in this case where we have one tree
per parent vnode instead of one global hash. This also allows better
locking granularity (if that will
On Fri, Jun 12, 2009 at 07:51:48AM +0200, Otto Moerbeek wrote:
> On Thu, Jun 11, 2009 at 03:51:12PM -0600, Bob Beck wrote:
>
> >
> > I could use some assistance in testing this, particularly on some of
> > the more odd archetectures.
> >
> > This diff makes a bunch of changes to the vfs
On Thu, Jun 11, 2009 at 03:51:12PM -0600, Bob Beck wrote:
>
> I could use some assistance in testing this, particularly on some of
> the more odd archetectures.
>
> This diff makes a bunch of changes to the vfs name cache:
>
> 1) it gets rid of the global hash table and reverse has
I could use some assistance in testing this, particularly on some of
the more odd archetectures.
This diff makes a bunch of changes to the vfs name cache:
1) it gets rid of the global hash table and reverse hash table for namecahe
entries. namecache entries
are now allocated
On Saturday 23 May 2009 15:59:06 Brad wrote:
> Please test the following diff if you have a de(4) Ethernet
> adapter. This should fix the issues with the bus_dma map
> handling. Already tested by matthieu@ on an alpha.. so I'm
> looking for some further testing.
Anyone? I'd really like to remove t
There are a few developers who could use some more hardware.
These items have been added recently to http://www.openbsd.org/want.html
- thib@ in Iceland would like a smallish NetApp (like a FAS250 or such)
so that he can improve our NFS codebase more
- damien@ would like a huge pile of Atheros
On Thu, 2009-06-11 at 01:06 -0400, Brad wrote:
> Please test the following diff for brgphy(4), especially for bge(4).
> Also for bnx(4) and gem(4), any other NICs if I've forgotten any.
Seems to be working fine.
> Please send a full dmesg.
OpenBSD 4.5-current (GENERIC) #0: Thu Jun 11 14:05:05 CS
