linux-kernel - [PATCH v3 2/3] common: DMA-mapping: add DMA_ATTR

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: <1452109005-19517-3-git-send-email-dianders@chromium.org>
Date:	Wed,  6 Jan 2016 11:36:44 -0800
From:	Douglas Anderson <dianders@...omium.org>
To:	Russell King <linux@....linux.org.uk>
Cc:	Robin Murphy <robin.murphy@....com>,
	Tomasz Figa <tfiga@...omium.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Pawel Osciak <pawel@...iak.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Douglas Anderson <dianders@...omium.org>, corbet@....net,
	akpm@...ux-foundation.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH v3 2/3] common: DMA-mapping: add DMA_ATTR_SEQUENTIAL attribute

This patch adds the DMA_ATTR_SEQUENTIAL attribute to the DMA-mapping
subsystem.

This attribute can be used as a hint to the DMA-mapping subsystem that
access to memory will be mostly sequential.  With mostly sequential
access TLB efficiency isn't as important, so the system may make
tradeoffs sacrificing TLB efficiency to gain other benefits.

It's expected that we will use this attribute as a hint that memory
allocation should be done page at a time instead of asking the memory
subsystem to try to give us as big of chunks as possible.  Allocating a
page at a time sacrifices TLB efficiency but it is much quicker for the
memory subsystem to process and it also leaves big chunks of memory
available for other users to use.

The name of the hint (DMA_ATTR_SEQUENTIAL) is based on the name
MADV_SEQUENTIAL, which has the same meaning.  If we have expected users,
we could also add DMA_ATTR_RANDOM to indicate that random access is
expected.

Signed-off-by: Douglas Anderson <dianders@...omium.org>
---
Changes in v3:
- add DMA_ATTR_SEQUENTIAL attribute new for v3

Changes in v2: None

 Documentation/DMA-attributes.txt | 11 +++++++++++
 include/linux/dma-attrs.h        |  1 +
 2 files changed, 12 insertions(+)

diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
index 18dc52c4f2a0..467e1c5c9cdc 100644
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -100,3 +100,14 @@ allocated by dma_alloc_attrs() function from individual pages if it can
 be mapped as contiguous chunk into device dma address space. By
 specifying this attribute the allocated buffer is forced to be contiguous
 also in physical memory.
+
+DMA_ATTR_SEQUENTIAL
+-------------------
+
+This is a hint to the DMA-mapping subsystem that access to the buffer
+will be mostly sequential instead of random access.  The DMA-mapping
+subsystem might use this information to make decisions on how hard it
+will work to optimize TLB efficiency.  If we know access is sequential
+and we don't have DMA_ATTR_FORCE_CONTIGUOUS then it's probably wiser
+for the DMA-mapping subsystem to allocate memory out of individual
+pages to avoid stressing the memory subsystem as much.
diff --git a/include/linux/dma-attrs.h b/include/linux/dma-attrs.h
index 99c0be00b47c..5777a2cec5f3 100644
--- a/include/linux/dma-attrs.h
+++ b/include/linux/dma-attrs.h
@@ -18,6 +18,7 @@ enum dma_attr {
 	DMA_ATTR_NO_KERNEL_MAPPING,
 	DMA_ATTR_SKIP_CPU_SYNC,
 	DMA_ATTR_FORCE_CONTIGUOUS,
+	DMA_ATTR_SEQUENTIAL,
 	DMA_ATTR_MAX,
 };
 
-- 
2.6.0.rc2.230.g3dd15c0

--
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/