Summary list of ARs from this meeting: AR for Joel: Find an open source fragmentation avoidance test and post it on the list. AR for Russ: Contact Christoph Lameter for input on fragmentation testing. AR for Mary: Post on the wiki the list of possible regression tests for hotplug memory that were discussed in this con call AR for Martine: Post use case on virtualization to hotplug and virtualization mailing lists for feedback AR for Martine and Mary: Contact Sylvester for an update on the dynamic partitioning use case. ################################# Attendees: George Mann, Individual contributor Joel Schopp, IBM Mary Edie Meredith, OSDL Mark Wong, OSDL Mark Delcambre, OSDL Russ Anderson, SGI Bruce Vessey, Unisys Natalie Protasevich, Unisys Martine Silbermann, HP * Reporting tool/format for automated tests The consensus seemed to be that a mail should only be sent out on the list in case of failure of one or more tests. The mail should have a pointer to the results as opposed to putting the results directly into the mail. We should keep a log of all the tests that have been run so that we can easily verify at what point in time a test started failing (makes it easier to determine what patches where added in between good and failing runs). This log would be kept over a period of time that depends on the frequency of the test runs. Currently test case 2, 3, 4 for CPU hotplug have scripts associated to them. Test case 6 has been done for TOP and Mary generated a list of all the other tools that we'll keep track of in the context of this test case. There's an existing script for test case 1 that will be integrated in the suite. Test case 5 is a stress test (which can also be used to keep track of performance changes). First Mary will use the database test to do stress testing; later on we might combine NFS and hotplug testing. The problem will be spotting problems in an automated way. The stress tests are expected to run over long periods of time. Besides the reporting tool it would be good to have a comparison tool that would compare results between 2 runs. This could be particularly useful for stress testing and to detect performance issues. The idea is to try to catch regressions by mapping a set of "reference" results (obtained from a known "good" kernel) against the test results obtained with hotplug patches applied to that kernel. * Discussion to identify memory hotplug common regressions As memory hotplug development is progressing, it is time to identify some key regression tests that should be done on the new patches and to develop a test plan for memory hotplug. For memory hot-add: Joel informed us that the hot-add patches have been sent to Andrew Morton and are expected to be accepted shortly. To test the hot-add patches we should boot the machine without all the available memory and then exercise the hot-add patches by adding the memory. The first thing to do is to verify that the memory was added, this should be easily seen in /proc/meminfo. As for seeing if this memory is actually used there were several suggestions made from instrumenting the kernel to running benchmarks like AIM and making sure we exhaust all the memory. There's a boot option (mem=xxxM) that allows you to override the amount of memory that the kernel detects for the machine at boot time. However it seems that this option doesn't work well on systems with sparse mem. We should also use statistics tools such as SAR to keep track of the added memory. For memory hot-remove: Since they will be part of the final solution for hot removing memory we should also test memory migration and memory defragmentation. Memory defragmentation can be viewed as 2 parts: fragmentation avoidance (which is an infrastructure change) and defragmentation for which there seems to be several approaches amongst them are Marcelo Tosatti's, Dave Hansen's (IBM) and Fujitsu's (no sure who the developer is: Hirokazu Takahasih?). AR for Joel: Find an open source fragmentation avoidance test and post it on the list. We had a discussion on how to measure the level of fragmentation of the memory at any given time. One of the simple approaches would be to try to do different orders of allocations and see which one fail and which one succeed (memory size of what fails can provide a fair indication of level of fragmentation). However is a memory alloc failure always a reliable indicator of memory fragmentation? Another possible indicator of the level of fragmentation is the time it takes to return from an alloc call. AR for Russ: Contact Christoph Lameter for input on fragmentation testing. We also discussed ways to determine how fragmented the slab cache is. Suggestions included writing specific tests for the slab cache and instrumenting the kernel. * Status of use cases. Martine has submitted a new version of the virtualization use case to the working group and will post it to the broader group for feedback. No update on the dynamic partitioning use case. AR for Martine: Post use case on virtualization to hotplug and virtualization mailing lists for feedback. AR for Martine and Mary: Contact Sylvester for an update on the dynamic partitioning use case. Next meeting is scheduled for August 30th at 11:00am -12:00pm PST, 2:00pm - 3:00pm EST. Thanks for your participation. Martine J. Silbermann -------------- next part -------------- _______________________________________________ Hotplug_sig mailing list Hotplug_sig@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/hotplug_sig
