[Intel-gfx] [PATCH 04/19] drm/i915/gt: Add helper for shmem copy to iosys_map

Lucas De Marchi lucas.demarchi at intel.com
Mon Feb 7 20:35:01 UTC 2022


On Fri, Feb 04, 2022 at 08:15:12PM +0100, Thomas Zimmermann wrote:
>Hi
>
>Am 04.02.22 um 18:44 schrieb Lucas De Marchi:
>>Add a variant of shmem_read() that takes a iosys_map pointer rather
>>than a plain pointer as argument. It's mostly a copy __shmem_rw() but
>>adapting the api and removing the write support since there's currently
>>only need to use iosys_map as destination.
>>
>>Reworking __shmem_rw() to share the implementation was tempting, but
>>finding a good balance between reuse and clarity pushed towards a little
>>code duplication. Since the function is small, just add the similar
>>function with a copy/paste/adapt approach.
>>
>>Cc: Matt Roper <matthew.d.roper at intel.com>
>>Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
>>Cc: Tvrtko Ursulin <tvrtko.ursulin at linux.intel.com>
>>Cc: David Airlie <airlied at linux.ie>
>>Cc: Daniel Vetter <daniel at ffwll.ch>
>>Cc: Matthew Auld <matthew.auld at intel.com>
>>Cc: Thomas Hellström <thomas.hellstrom at linux.intel.com>
>>Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
>>Signed-off-by: Lucas De Marchi <lucas.demarchi at intel.com>
>>---
>>  drivers/gpu/drm/i915/gt/shmem_utils.c | 33 +++++++++++++++++++++++++++
>>  drivers/gpu/drm/i915/gt/shmem_utils.h |  3 +++
>>  2 files changed, 36 insertions(+)
>>
>>diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c b/drivers/gpu/drm/i915/gt/shmem_utils.c
>>index 0683b27a3890..764adefdb4be 100644
>>--- a/drivers/gpu/drm/i915/gt/shmem_utils.c
>>+++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
>>@@ -3,6 +3,7 @@
>>   * Copyright © 2020 Intel Corporation
>>   */
>>+#include <linux/iosys-map.h>
>>  #include <linux/mm.h>
>>  #include <linux/pagemap.h>
>>  #include <linux/shmem_fs.h>
>>@@ -123,6 +124,38 @@ static int __shmem_rw(struct file *file, loff_t off,
>>  	return 0;
>>  }
>
>Here's a good example of how to avoid iosys_map_incr() and use the 
>memcpy offset:
>
>>+int shmem_read_to_iosys_map(struct file *file, loff_t off,
>>+			    struct iosys_map *map, size_t len)
>>+{
>>+	struct iosys_map map_iter = *map;
>
>Rather replace map_iter with something like
>
>  unsigned long map_off = 0;
>
>>+	unsigned long pfn;
>>+
>>+	for (pfn = off >> PAGE_SHIFT; len; pfn++) {
>>+		unsigned int this =
>>+			min_t(size_t, PAGE_SIZE - offset_in_page(off), len);
>>+		struct page *page;
>>+		void *vaddr;
>>+
>>+		page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
>>+						   GFP_KERNEL);
>>+		if (IS_ERR(page))
>>+			return PTR_ERR(page);
>>+
>>+		vaddr = kmap(page);
>>+		iosys_map_memcpy_to(&map_iter, 0, vaddr + offset_in_page(off),
>>+				    this);
>
>Use map_off to index into map directly.
>
>>+		mark_page_accessed(page);
>>+		kunmap(page);
>>+		put_page(page);
>>+
>>+		len -= this;
>>+		iosys_map_incr(&map_iter, this);
>
>Raplace iosys_map_incr() with map_off += this;
>
>>+		off = 0;
>
>Maybe off += this ?

Wouldn't that be wrong? AFAICS `off` is the offset of the file (source) and we
zero it here so just the first iteration considers it as a page offset -
next iterations are expected to copy whole pages or the remaining of the
buffer.

Encapsulating the dest offset calculation inside iosys_map with an iter
was a way to avoid this kind of bugs in places that need to keep track
of both source and dest.

Anyway, I disagree and commit here. I will change to map_off and think
about the other cases.

There are also some more complex cases in which copying the map
and work with it avoids other bugs that I will have to think about:

	- patch 9 ("drm/i915/guc: Convert engine record to
	  iosys_map"): as you already noticed we delegate its update to
	  other compilation unit

	- patch 11 ("drm/i915/guc: Convert golden context prep to iosys_map"):
	  info_map, which can point either to the real buffer (in system
	  or IO memory) or to a temporary buffer (system memory)

	- patch 17: it needs to write to 2 parts of struct: passing
	  different offsets depending on the call is IMO more error
	  prone than making sure we are working with the right variable.


thanks
Lucas De Marchi

>
>I think this pattern should be applied to all similar code. As you 
>already noted, iosys_map_incr() is problematic.
>
>Best regards
>Thomas
>
>>+	}
>>+
>>+	return 0;
>>+}
>>+
>>  int shmem_read(struct file *file, loff_t off, void *dst, size_t len)
>>  {
>>  	return __shmem_rw(file, off, dst, len, false);
>>diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.h b/drivers/gpu/drm/i915/gt/shmem_utils.h
>>index c1669170c351..e1784999faee 100644
>>--- a/drivers/gpu/drm/i915/gt/shmem_utils.h
>>+++ b/drivers/gpu/drm/i915/gt/shmem_utils.h
>>@@ -8,6 +8,7 @@
>>  #include <linux/types.h>
>>+struct iosys_map;
>>  struct drm_i915_gem_object;
>>  struct file;
>>@@ -17,6 +18,8 @@ struct file *shmem_create_from_object(struct drm_i915_gem_object *obj);
>>  void *shmem_pin_map(struct file *file);
>>  void shmem_unpin_map(struct file *file, void *ptr);
>>+int shmem_read_to_iosys_map(struct file *file, loff_t off,
>>+			    struct iosys_map *map, size_t len);
>>  int shmem_read(struct file *file, loff_t off, void *dst, size_t len);
>>  int shmem_write(struct file *file, loff_t off, void *src, size_t len);
>
>-- 
>Thomas Zimmermann
>Graphics Driver Developer
>SUSE Software Solutions Germany GmbH
>Maxfeldstr. 5, 90409 Nürnberg, Germany
>(HRB 36809, AG Nürnberg)
>Geschäftsführer: Ivo Totev





More information about the Intel-gfx mailing list