On Tue, Apr 19, 2016 at 06:25:32PM +0200, Jesper Dangaard Brouer wrote: > On Mon, 18 Apr 2016 07:17:13 -0700 > Eric Dumazet <eric.duma...@gmail.com> wrote: > > > On Mon, 2016-04-18 at 16:05 +0300, Saeed Mahameed wrote: > > > On Mon, Apr 18, 2016 at 3:48 PM, Eric Dumazet <eric.duma...@gmail.com> > > > wrote: > > > > On Sun, 2016-04-17 at 17:29 -0700, Eric Dumazet wrote: > > > > > > > >> > > > >> If really you need to allocate physically contiguous memory, have you > > > >> considered converting the order-5 pages into 32 order-0 ones ? > > > > > > > > Search for split_page() call sites for examples. > > > > > > > > > > > > > > Thanks Eric, we are already evaluating split_page as we speak. > > > > > > We did look but could not find any specific alloc_pages API that
alloc_pages_exact() > > > allocates many physically contiguous pages with order0 ! so we assume > > > it is ok to use split_page. > > > > Note: I have no idea of split_page() performance : > > Maybe Mel knows? Irrelevant in comparison to the cost of allocating an order-5 pages if one is not already available. > And maybe Mel have an opinion about if this is a good > or bad approach, e.g. will this approach stress the page allocator in a > bad way? > It'll contend on the zone lock minimally but again, irrelevant in comparison to having to reclaim/compact an order-5 page if one is not already free. It'll appear to work well in benchmarks and then fall apart when the system is running for long enough.
