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

Matt Helsley matthltc at us.ibm.com
Wed Oct 21 23:40:07 PDT 2009


On Wed, Oct 21, 2009 at 09:59:50AM -0500, Serge E. Hallyn wrote:
> Quoting Matt Helsley (matthltc at us.ibm.com):
> > 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 at us.ibm.com>
> 
> 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.

> 
> Acked-by: Serge Hallyn <serue at us.ibm.com>

<snip>

For anyone who's curious, it's only 7 additional lines (++ below).

> > ++  int nchunk;
...
> > ++	nchunk = num_items;
> > ++	do {
> > +		items = kzalloc(sizeof(*items)*nchunk, GFP_KERNEL);
> > ++		if (items)
> > ++			break;
> > ++		nchunk = nchunk >> 1;
> > ++	} while (nchunk > 0);
> >  	if (!items)
> >  		return -ENOMEM;

<snip>

Cheers,
	-Matt Helsley
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list