Jarek Pelczar's performance optimizations

[pulkomandy]

For the record, so that doesn't get lost since it was just mentionned in irc, Jarek is working on some optimizations to the kernel:

​https://github.com/jarekpelczar/haiku/commits/jarek

I guess the use of Boost for data structures may be controversial, but, if their implementation is better than ours, I think it's ok and it avoids reinventing the wheel. Some of the changes also do not require boost.

[waddlesplash]

I am skeptical that some of these changes provide any real benefit at all; the "improved name store" for the port heap, for example. And if Boost's data structures (AVL trees, etc.) are really faster than ours, surely we can just optimize ours.

[tqh]

I don't think a third party dependency for crucial data structures is the right way.

Making sure that it is kernel safe and not using exceptions, RTTI, work on all architectures, works with gcc2 etc is going to be more pain.

Also I want to be able to view the code in our tree as well..

[korli]

Replying to tqh:

architectures, works with gcc2 etc is going to be more pain.

there is no gcc2 in the kernel anymore.

[waddlesplash]

One change inspired by one of his: ​https://review.haiku-os.org/c/haiku/+/8177

Negligible if any performance improvement that I've seen so far.

[waddlesplash]

Committed one of the changes in hrev58050, didn't see any significant performance improvement though.

[pulkomandy]

I don't think a third party dependency for crucial data structures is the right way.

It was not done as a dependency, but by importing some files from boost into haiku sources. So at least the build system part of this is not a problem, and the code is in the sourcetree. It's not really different from libc code imported from glibc or musl or FreeBSD: if someone already wrote a good imhlementation of something, we can reuse it.

At the moment it's unclear if this is really a herformance gain (no benchmarks were provided), and if the gain can easily be obtained in a different way (imhroving our avl tree implementation instead of using boost one).

[waddlesplash]

Two more that look interesting: ​https://github.com/jarekpelczar/haiku/commit/fdcbbd6d67b60d0669ee6bce5dac57153f7d1fc2 (page reservation priority tree, and also use ConditionVariable to wait), and ​https://github.com/jarekpelczar/haiku/commit/7f996e2b01ea82fbe4c183acd1087b3826a5f8b5 (release pages in bulk instead of one at a time, avoids more wakeups in low-memory state.)

[waddlesplash]

​https://github.com/jarekpelczar/haiku/commit/cb512a542d6cc0b700e48f56895cd799a8684503 (bulk page allocations and deallocations)

​https://github.com/jarekpelczar/haiku/commit/911ed5a4dc83c286fe8a8bd036fbeaa1c6381740 and ​https://github.com/jarekpelczar/haiku/commit/d59a4b9577da99114b531e4b050c360b44151bd7 and ​https://github.com/jarekpelczar/haiku/commit/019baa04927ad330ffed5c249205b0f0f5c57d24 (avoid SEQ_CST where possible, more relevant on non-x86)

​https://github.com/jarekpelczar/haiku/commit/9cd34c69dc6ba46292645936f0b625c410ac8982 (don't remove low resource handlers while running)

​https://github.com/jarekpelczar/haiku/commit/5cce770c064e61677ea536d5fef3ae65d01b6dc4 (discard entry caches on low memory)

(All of these would require careful review for correctness and rework to make them more idiomatic, though.)

All the changes about not waiting for page reservations look like they're covering up for bugs. By the time we are reserving pages we should only do so having already reserved memory. If we are trying to reserve pages that we haven't reserved memory for, then there's a bug.

[waddlesplash]

Merged a few of the minor ones in hrev58112.

[waddlesplash]

Implemented some of the "bulk page release" logic in hrev58466.