Re: [PATCH 2/3] epoll: Add support for checkpointing large numbers of epoll items

[Oren Laadan <orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>]

Matt Helsley wrote:
> On Wed, Oct 21, 2009 at 09:59:50AM -0500, Serge E. Hallyn wrote:
>> Quoting Matt Helsley (matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org):
>>> 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-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>> 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.