Hi all, here is a summary of the state of the CHT (Concurrent Hash Table) pre-integration branch for broader audience.
First of all, the branch is located at: lp:~jakub/helenos/cht-preintegration https://code.launchpad.net/~jakub/helenos/cht-preintegration Even though I am still facing some issues, to make the long story short, I am going to merge this shortly after the 0.6.0 release. Anything below is just details that you can safely ignore, if you don't care about CHT and RCU. The original CHT branch contains roughly: - two flavours of kernel RCU and one flavour of userspace RCU - the concurrent hash table (CHT) that makes use of kernel RCU - speedup of futex lookup (using a per task CHT) - userspace-RCU-protected upgrading of certain userspace no-op futexes to full futexes when the task has multiple threads - a couple of important but otherwise unrelated kernel bugs What I have done: - merged the CHT branch into my pre-integration branch - made sure it compiles on all architectures - made sure it runs on all architectures Making sure the CHT pre-integration branch runs on all architectures was actually quite challenging. The main problem was that some of the more exotic architectures (namely ia64 and sparc64/sun4[uv]) did not channel traps/exceptions trough the generic exc_dispatch() mechanism, which is necessary, among other things, for proper accounting of CPU states (idle/non-idle). Since the implemented RCU algorithms seem to be especially picky about that, the system would hit a CPU state assertion sooner or later. So the majority of my pre-integration effort went into rewriting the ia64 and sparc64 trap handling code. The good thing about that is that I managed to clean up the code a little bit and fix some latent bugs along the way. Here are some of the bugs that I noticed: #605 PREEMPTIBLE_HANDLER_KERNEL needs to spill uspace windows to uspace wbuf #606 VFS sometimes crashes in fibril_switch() on sun4v #607 Nested traps should probably lower GL too to avoid register corruption XXX I am sometimes observing a crash in which a code page of a task is overwritten by a pattern which contains the kernel address of the sentinel node (which is a static variable used by the CHT itself) I have already fixed #605 in my branch and have developed a fix for #607 (even though I am still not sure whether/how does that bug manifest itself). I am puzzled about XXX. It happens on sparc64/sun4v where we have a task with multiple threads and thus it uses full futexes and CHT. It seems to me like I am looking at a buffer, which had been used for CHT resizing. I wish *Adam* could comment on this a little bit. Even with #606 and XXX still unresolved, the sun4v port is still quite usable, so I am going to merge anyway. Unfortunately, the only platform that I didn't fix wrt. to CHT is sparc32, which I expect to have similar issues as sparc64. The problem here is that so far I have not been successful in booting the sparc32 system. And that's all! I would be grateful for any comments and/or code reviews. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
