| 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
| ||
|
Date: Fri, 13 Nov 2009 10:17:36 +0100 From: Andi Kleen <andi@...stfloor.org> To: Dan Williams <dan.j.williams@...el.com> Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-mm@...ck.org Subject: Re: GFP_ATOMIC versus GFP_NOWAIT Dan Williams <dan.j.williams@...el.com> writes: > Looking through the tree it seems that almost all drivers that need to > allocate memory in atomic contexts use GFP_ATOMIC. I have been asking > dmaengine device driver authors to switch their atomic allocations to > GFP_NOWAIT. The rationale being that in most cases a dma device is > either offloading an operation that will automatically fallback to > software when the descriptor allocation fails, or we can simply poll > and wait for the dma device to release some in use descriptors. So it > does not make sense to grab from the emergency pools when the result > of an allocation failure is some additional cpu overhead. Am I > correct in my nagging, and should this idea be spread outside of > drivers/dma/ to cut down on GFP_ATOMIC usage, or is this not a big > issue? It's probably hard to find a good global priority order between the various allocators, depending on how much the fallback costs. But in principle it sounds like a good idea. -Andi -- ak@...ux.intel.com -- Speaking for myself only. -- 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