Matt Helsley wrote: > On Wed, Oct 21, 2009 at 09:59:50AM -0500, Serge E. Hallyn wrote: >> Quoting Matt Helsley (matthltc@xxxxxxxxxx): >>> Currently we allocate memory to output all of the epoll items in one >>> big chunk. At 20 bytes per item, and since epoll was designed to >>> support on the order of 10,000 items, we may find ourselves kmalloc'ing >>> 200,000 bytes. That's an order 7 allocation whereas the heuristic for >>> difficult allocations, PAGE_ALLOC_COST_ORDER, is 3. >>> >>> Instead, output the epoll header and items separately. Chunk the output >>> much like the pid array gets chunked. This ensures that even sub-order 0 >>> allocations will enable checkpoint of large epoll sets. A subsequent >>> patch will do something similar for the restore path. >>> >>> Signed-off-by: Matt Helsley <matthltc@xxxxxxxxxx> >> Feels a bit auto-tune-magic-happy :) but looks good > > Well it's not magic compared to guessing what a good number would be. > There can be lots of these items and I figured that writing them in > the biggest chunks possible could be useful. What qualifies as a "good" number ? Performance wise, I suspect there isn't much difference between 4K, 8K and above buffers in practice, compared to the total checkpoint time. Oren. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
