linux-kernel - Re: [Myricom help #56546] Re: 2.6.24 Page Allocation Failure

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>] [day] [month] [year] [list]

Message-ID: <47A335CA.1020301@myri.com>
Date:	Fri, 01 Feb 2008 10:07:54 -0500
From:	Andrew Gallatin <gallatin@...i.com>
To:	AndrewL733 <AndrewL733@....com>
CC:	linux-kernel@...r.kernel.org,
	Myricom Technical Support <help@...i.com>
Subject: Re: [Myricom help #56546] Re: 2.6.24 Page Allocation Failure

AndrewL733 wrote:
 > The cause of this problem seems to be compiling the Myricom driver with
 > the ALLOC_ORDER=2 option. When I use the in-kernel driver, (1.3.2) or
 > recompile the Myricom 1.4.0 driver WITHOUT the option, the problem seems
 > to go away even after heavy hammering of the system.
 >
 > The ALLOC_ORDER=2 compiling option doesn't seem to cause any problem for
 > the Myricom 1.4.0 driver in the 2.6.22 kernel but it does cause the
 > problem when I run it in 2.6.24.

High order allocations are much harder to satisfy than single page
allocations, which is why we default MYRI10GE_ALLOC_ORDER to zero.
Part of the reason why we receive into pages rather than plain skbs is
to be able to use jumbo frames without high order allocations.  In
your case, I suspect that "something" changed enough between 2.6.22
and 2.6.24 that caused the high order allocations to start failing
under the same workload.  I don't know enough about the VM system
to know what changed.

In some quick experiments here, it seems that most of the cost of
these failures is the console messages that they generate.  The driver
is written such that failures like this can be tolerated.  I think the
warning should just be disabled for our rx buffer allocations.

I've attached a patch (against 1.4.0) which does this.  When running a
memory hog which repeatedly reads one byte per page of an array larger
than physical memory, I still see line rate with this patch applied.
Without the patch, I see a few hundred Mb/s and constant page
allocation warnings.  Please note that this disables the warnings just
for our rx buffer allocations.  Other allocations done elsewhere in
the system may still generate warnings if the system is under heavy
memory pressure.

Drew

View attachment "nowarn.diff" of type "text/plain" (653 bytes)