Hi Adam, On 07/10/2012 08:47 PM, Adam Hraska wrote: > I've pushed some of my recent changes to launchpad. It > currently includes particularly: > > 1) A preemptible rcu (unlike the algos described in my past > rcu review mail) implementation as well as stress tests > and a couple of tests targeted at corner/special cases. > Run "test rcu1" to run the tests. To see basic statistics > type "rcu" in the kernel console. > > 2) A workqueue/thread pool that expands and shrinks depanding > on the current load and blocking/sleeping of work functions. > Run "test workqueue" to stress test. "workq" in the kconsole > again shows some state. > > The work queue tries to minimize creating/destroying and > sleeping/waking up of work queue threads. It can be used if > an rcu callback needs to block (which it is not allowed to > directly from the callback invoked by rcu_call). Moreover, it > will be used to resize hash tables in the background. > > 3) Some minor additions. Eg a facility to call functions > on other cpus (built on top of IPIs) and wait for them > to return. "test smpcall1" runs tests. > > Bear in mind that all tests were conducted in qemu on my > Pentium M machine (ia32, uniprocessor, lacking hardware > virtualization).
Yesterday I cloned your branch and after fixing some minor issues with symbolic links and 64-bit printf formatters, I tried out the functionality you describe above on both ia32 and amd64. Since you pushed basically all your changesets at the very last moment (instead of pushing them steadily through out the whole span of initial 7 weeks of the coding period), it will take me some time to review them. I will try to go through them tomorrow, but I am not sure I can handle everything before the midterm evaluation ends. There is one thing I noticed. When I run the tests, such as rcu1, with -smp 7, the kernel runs out of memory and deadlocks while waiting in vain for more memory to arrive. Have you noticed that too? Do you know what is causing it? Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
