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: <alpine.DEB.2.00.1210031104120.29765@chino.kir.corp.google.com>
Date:	Wed, 3 Oct 2012 11:07:13 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Stanislaw Gruszka <sgruszka@...hat.com>
cc:	Mel Gorman <mgorman@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Machek <pavel@....cz>, linux-wireless@...r.kernel.org,
	johannes.berg@...el.com, wey-yi.w.guy@...el.com,
	ilw@...ux.intel.com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: iwl3945: order 5 allocation during ifconfig up; vm problem?

On Wed, 3 Oct 2012, Stanislaw Gruszka wrote:

> So, can this problem be solved like on below patch, or I should rather
> split firmware loading into chunks similar like was already iwlwifi did?
> 
> diff --git a/drivers/net/wireless/iwlegacy/common.h b/drivers/net/wireless/iwlegacy/common.h
> index 5f50177..1b58222 100644
> --- a/drivers/net/wireless/iwlegacy/common.h
> +++ b/drivers/net/wireless/iwlegacy/common.h
> @@ -2247,7 +2247,7 @@ il_alloc_fw_desc(struct pci_dev *pci_dev, struct fw_desc *desc)
>  
>  	desc->v_addr =
>  	    dma_alloc_coherent(&pci_dev->dev, desc->len, &desc->p_addr,
> -			       GFP_KERNEL);
> +			       GFP_KERNEL | __GFP_REPEAT);
>  	return (desc->v_addr != NULL) ? 0 : -ENOMEM;
>  }
>  

I think this will certainly make memory compaction more aggressive by 
avoiding the logic to defer calling compaction in the page allocator, but 
because we lack lumpy reclaim this still has a higher probability of 
failing than it had in the past because it will fail if 128KB of memory is 
reclaimed that may not happen to be contiguous for an order-5 allocation 
to succeed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ