kernel/fs: Add missing initializations to EntryCache.

Should fix #17857.

kernel/fs: Larger sizes for EntryCache if there is >= 1GB RAM available.

Instead of 8096 maximum entries, now there will be about 130k.
As there are around ~32k files in the Haiku git tree, this has a
serious impact on "git status" performance: in my testing it sped up
from around 0.95s to 0.39s, or less than half with a "hot" cache
(in a VM backed by an NVMe SSD, may be more dramatic on spinning system.)

Compile performance does not seem very much improved, however.

kernel/fs: Fix generation reference in EntryCache.

We are trying to add the enty to the current generation, so we
need to use the current generation's next_index, not the previous.
This was apparently broken since this code was imported. The "miss"
here meant we always acquired the write-lock and then ran the more
expensive add operation, which performs this same check (correctly).

Slight performance improvement seen in basic testing, but nothing
too drastic.

kernel/fs: Refactor EntryCache to not use constant array sizes.

Instead set them in the Init functions. For now, the same
hard-coded sizes are used, so aside from slightly increased storage
on two classes (or not even due to padding), this has no functional change.

EntryCache: Add entry_cache_add_missing() for negative caching.

It provides a way for filesystems to cache a lookup failure and
therefore prevents repeated lookups of missing entries. This is a
common scenario for example in command lookup and compiling, where
each directory in PATH or each include directory is searched for the
given entry.

kernel: atomic_*() functions rework

* No need for the atomically changed variables to be declared as
volatile.
* Drop support for atomically getting and setting unaligned data.
* Introduce atomic_get_and_set[64]() which works the same as
atomic_set[64]() used to. atomic_set[64]() does not return the
previous value anymore.

Added DebugReverseLookup() method to reverse-lookup directory and entry name
for a given vnode (for debugging purposes).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35625 a95241bf-73f2-0310-859d-f6bbb57e9c96

Entry cache:
* Moved hash computations out of the critical sections.
* Replaced the LRU entry queue by an array of entry "generations", each
containing a sparse array of entries of that generation. Whenever a
generation is full, we clear the oldest generation and continue with that
one. The main advantage of this algorithm is that entry cache's mutex could
be replaced by an r/w lock, that most of the time only has to be read
locked in Lookup(). This does dramatically decrease contention of that
lock.

The total -j8 Haiku image build speedup is marginal, but the kernel time
drops about 7% (now being smaller than the real time).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34950 a95241bf-73f2-0310-859d-f6bbb57e9c96

EntryCache: Add entry_cache_add_missing() for negative caching.

It provides a way for filesystems to cache a lookup failure and
therefore prevents repeated lookups of missing entries. This is a
common scenario for example in command lookup and compiling, where
each directory in PATH or each include directory is searched for the
given entry.

kernel: atomic_*() functions rework

* No need for the atomically changed variables to be declared as
volatile.
* Drop support for atomically getting and setting unaligned data.
* Introduce atomic_get_and_set[64]() which works the same as
atomic_set[64]() used to. atomic_set[64]() does not return the
previous value anymore.

Added DebugReverseLookup() method to reverse-lookup directory and entry name
for a given vnode (for debugging purposes).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35625 a95241bf-73f2-0310-859d-f6bbb57e9c96

Entry cache:
* Moved hash computations out of the critical sections.
* Replaced the LRU entry queue by an array of entry "generations", each
containing a sparse array of entries of that generation. Whenever a
generation is full, we clear the oldest generation and continue with that
one. The main advantage of this algorithm is that entry cache's mutex could
be replaced by an r/w lock, that most of the time only has to be read
locked in Lookup(). This does dramatically decrease contention of that
lock.

The total -j8 Haiku image build speedup is marginal, but the kernel time
drops about 7% (now being smaller than the real time).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34950 a95241bf-73f2-0310-859d-f6bbb57e9c96