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 > > 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? 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? > Buddy page allocator has to aggregate pages into order-5, then we would > undo the work, touching 32 cache lines. > > You might first benchmark a simple loop doing > > loop 10,000,000 times > Order-5 allocation > split into 32 order-0 > free 32 pages > > > Another idea would be to have a way to control max number of order-5 > pages that a port would be using. > > Since driver always own a ref on a order-5 pages, idea would be to > maintain a circular ring of up to XXX such pages, so that we can detect > an abnormal use and fallback to order-0 immediately. That is part of my idea with my page-pool proposal. In the page-pool I want to have some watermark counter that can block/stop the OOM issue at this RX ring level. See slide 12 of presentation: http://people.netfilter.org/hawk/presentations/MM-summit2016/generic_page_pool_mm_summit2016.pdf -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer
