linux-kernel - Re: [PATCH] mm: page_alloc: High-order per-cpu page allocator v7

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161208151101.pigfrnqd5i4n45uv@techsingularity.net>
Date:   Thu, 8 Dec 2016 15:11:01 +0000
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Christoph Lameter <cl@...ux.com>,
        Michal Hocko <mhocko@...e.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Johannes Weiner <hannes@...xchg.org>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Linux-MM <linux-mm@...ck.org>,
        Linux-Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: page_alloc: High-order per-cpu page allocator v7

On Thu, Dec 08, 2016 at 03:48:13PM +0100, Jesper Dangaard Brouer wrote:
> On Thu, 8 Dec 2016 11:06:56 +0000
> Mel Gorman <mgorman@...hsingularity.net> wrote:
> 
> > On Thu, Dec 08, 2016 at 11:43:08AM +0100, Jesper Dangaard Brouer wrote:
> > > > That's expected. In the initial sniff-test, I saw negligible packet loss.
> > > > I'm waiting to see what the full set of network tests look like before
> > > > doing any further adjustments.  
> > > 
> > > For netperf I will not recommend adjusting the global default
> > > /proc/sys/net/core/rmem_default as netperf have means of adjusting this
> > > value from the application (which were the options you setup too low
> > > and just removed). I think you should keep this as the default for now
> > > (unless Eric says something else), as this should cover most users.
> > >   
> > 
> > Ok, the current state is that buffer sizes are only set for netperf
> > UDP_STREAM and only when running over a real network. The values selected
> > were specific to the network I had available so milage may vary.
> > localhost is left at the defaults.
> 
> Looks like you made a mistake when re-implementing using buffer sizes
> for netperf.

We appear to have a disconnect. This was reintroduced in response to your
comment "For netperf I will not recommend adjusting the global default
/proc/sys/net/core/rmem_default as netperf have means of adjusting this
value from the application".

My understanding was that netperfs means was the -s and -S switches for
send and recv buffers so I reintroduced them and avoided altering
[r|w]mem_default.

Leaving the defaults resulted in some UDP packet loss on a 10GbE network
so some upward adjustment.

>From my perspective, either adjusting [r|w]mem_default or specifying -s
-S works for the UDP_STREAM issue but using the switches meant only this
is affected and other loads like sockperf and netpipe will need to be
evaluated separately which I don't mind doing.

> See patch below signature.
> 
> Besides I think you misunderstood me, you can adjust:
>  sysctl net.core.rmem_max
>  sysctl net.core.wmem_max
> 
> And you should if you plan to use/set 851968 as socket size for UDP
> remote tests, else you will be limited to the "max" values (212992 well
> actually 425984 2x default value, for reasons I cannot remember)
> 

The intent is to use the larger values to avoid packet loss on
UDP_STREAM.

-- 
Mel Gorman
SUSE Labs