On Thu, Jul 12, 2012 at 1:35 AM, Jakub Jermar <[email protected]> wrote: > 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.
Sorry about that. Fixed in rev 1554. > 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? There was a memory leak in the last stress test. It leaked about 60 MB of memory. I did not bother to check for memory leaks as synch/rcu.c itself does not allocate any memory. Lesson learned. What RAM size did you run the test with? I have been testing with the default RAM size (~380MB), because for some strange reason HelenOS did not survive the boot the first couple of times I tried booting with 30MB and 50MB (hanged after 10-25 lines of the initial blue boot screen in the middle of printf()). I could not reproduce the issue since, so I assume qemu simply misbehaved on my computer those first couple of times. Did you ever encounter a similar problem? Please note, that RCU in general is prone to exhausting all memory if it is not able to keep up with arriving callbacks. That is exactly what the last test stresses. I left the test enabled because the implementation seemed to keep up in my test setting. In any case I changed the test to use ATOMIC_FRAME. Otherwise it would grind to a near halt (ie take forever) if memory was scarce. On a different note: Please do not freak out that I reimplemented list_concat() (and with a clumsy name list_append_list()). Today, I finally noticed list_concat() exists and started using it ;-). Adam _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
