linux-kernel - GFP_ATOMIC versus GFP

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: <e9c3a7c20911121728n647ab121l7f7c5827afdac887@mail.gmail.com>
Date:	Thu, 12 Nov 2009 18:28:18 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-mm@...ck.org
Subject: GFP_ATOMIC versus GFP_NOWAIT

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?

Thanks,
Dan
--
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/