On Mon, 2005-10-10 at 13:30 -0700, Dave Hansen wrote: > On Mon, 2005-10-10 at 15:30 -0400, Silbermann, Martine wrote: > > * Memory hotplug common regressions - testing plan. > > Please take a few minutes to read the proposed testing plan (issued from > > the discussions we had in the last 2 meetings) and provide your > > comments/suggestions/additions either by mail or live during tomorrow's > > meeting. > > http://www.developer.osdl.org/maryedie/HOTPLUG/planning/hotplug_memory_t > > est_plan_status.html > > The description of the fragmentation tests looks a bit too complex to > me. There are some less invasive > > You measure slab fragmentation by looking at the first two columns > of /proc/slabinfo. The first is the number of objects which have been > handed outside the slab. The second is the number of objects that have > already have memory in the slab allocated to them, but have not been > allocated outside the slab cache itself. The first column may never be > larger than the second. The farther apart the values in the two > columns, the more slab fragmentation you have. > Definitely less invasive, and easier to implement. Thx. > To measure fragmentation of the buddy allocator, you must use a > different method: look at /proc/buddyinfo. The first column is the > number of (2^0 * PAGE_SIZE) pages available. The second column is the > number of (2^1 * PAGE_SIZE) pages available. These go all the way up to > MAX_ORDER-1. > > You must force the system to free up as many pages as it can, then look > at buddyinfo again. A perfectly non-fragmenting system will have no > column with a value of greater than 1. Any column with a larger value > is an indicator of fragmentation. Larger number is columns farther to > to the left indicate larger levels of fragmentation. Sorry if this is a dumb question but how do you force the system to free as many pages as it can? Thanks for your input, very helpful stuff. Martine > > -- Dave >
