Ok, this *used* to work, but I have some test reports
now that it will likely panic. so please hold off.
Sorry about that
-Bob
* Bob Beck [2009-08-09 03:41]:
> Ok let's try this again:
>
> >
> > I could use some assistance in testing this, particularly on so
Ok let's try this again:
>
> 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
> e
Thordur I. Bjornsson schrieb:
Dorian B|ttner wrote on Fri 12.Jun'09 at 19:25:05 +0200
AFAIK the whole work was done to make the cache more sane. The current
version is just insane enough that Bob was crying, shouting and playing
with red wine bottles during c2k9.
Hi Bob,
On Sat, Jun 13, 2009 at 12:52:11PM +, Thordur I. Bjornsson wrote:
> Dorian B|ttner wrote on Fri 12.Jun'09 at 19:25:05
> +0200
>
> AFAIK the whole work was done to make the cache more sane. The current
> version is just insane enough that Bob was crying, shouting and playing
>
Dorian B|ttner wrote on Fri 12.Jun'09 at 19:25:05 +0200
AFAIK the whole work was done to make the cache more sane. The current
version is just insane enough that Bob was crying, shouting and playing
with red wine bottles during c2k9.
> Hi Bob,
>
> tried your patch, got
AFAIK the whole work was done to make the cache more sane. The current
version is just insane enough that Bob was crying, shouting and playing
with red wine bottles during c2k9.
Hi Bob,
tried your patch, got a kernel panic with it and took some screen shots
with my digicam. Due to the pa
> > This is mostly theoretical. Most hash tables are badly sized and have
> > often bad hashing algorithms that tend to cause long linear list.
>
> So fix the sizing and use a proper hash algorithm. Indeed, it's more
> difficult if sizing is hard.
>
> I'm not against trees, but I like to see prop
On Fri, Jun 12, 2009 at 07:23:29PM +0200, Artur Grabowski wrote:
> Otto Moerbeek writes:
>
> >> AFAIK the whole work was done to make the cache more sane. The current
> >> version is just insane enough that Bob was crying, shouting and playing
> >> with red wine bottles during c2k9.
> >
> > That
Otto Moerbeek writes:
>> AFAIK the whole work was done to make the cache more sane. The current
>> version is just insane enough that Bob was crying, shouting and playing
>> with red wine bottles during c2k9.
>
> That's not enough reason to change the data structure.
Yes, it is. Code is primaril
On Fri, Jun 12, 2009 at 08:08:40AM +0200, Claudio Jeker wrote:
> > What's the reason to move to RB trees? In general they are slower,
> > have larger memory overhead and cause more memory fragmentation than
> > hash tables. The last thing is fixed by using pools, but the other two
> > things remai
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
14 matches
Mail list logo
