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-next>] [day] [month] [year] [list]
Message-Id: <1393340666-3539-1-git-send-email-mschmidt@redhat.com>
Date:	Tue, 25 Feb 2014 16:04:23 +0100
From:	Michal Schmidt <mschmidt@...hat.com>
To:	davem@...emloft.net
Cc:	netdev@...r.kernel.org, ariele@...adcom.com, dmitry@...adcom.com,
	yuvalmin@...adcom.com
Subject: [PATCH net-next 0/3] bnx2x: minimize RAM usage in kdump

kdump kernels usually have only a small amount of memory reserved.
bnx2x can be memory-hungry. Let's minimize its memory usage when
running in kdump.

I detect kdump by looking at the "reset_devices" flag. A couple of
storage drivers (cciss, hpsa) use it for the same purpose. I am not sure
this is the best way to solve the problem, but it works.

Should it be made more generic by, say, looking at the total amount
of lowmem instead? Not using TPA by default when lowmem is small and/or
defaulting to fewer queues would help 32bit systems where a driver for
a multi-function multi-queue NIC can consume a significant amount
of available memory. Or do we want no such heuristics?

Is this something to consider doing for other network drivers too?

Michal Schmidt (3):
  bnx2x: clamp num_queues to prevent passing a negative value
  bnx2x: save RAM in kdump kernel by using a single queue
  bnx2x: save RAM in kdump kernel by disabling TPA

 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c  | 12 ++++++++----
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |  2 ++
 2 files changed, 10 insertions(+), 4 deletions(-)

-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ