On Wed, Oct 21, 2009 at 09:59:50AM -0500, Serge E. Hallyn wrote:
> Quoting Matt Helsley (matth...@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 <matth...@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 <se...@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
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
_______________________________________________
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
