From: Daniel Vetter <daniel@ffwll.ch>
To: "Siluvery, Arun" <arun.siluvery@linux.intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [RFC] manage multiple entries of scratch page with scatterlist
Date: Thu, 12 Jun 2014 09:26:02 +0200 [thread overview]
Message-ID: <20140612072602.GU5821@phenom.ffwll.local> (raw)
In-Reply-To: <5398EB1B.6070208@linux.intel.com>
On Thu, Jun 12, 2014 at 12:49:47AM +0100, Siluvery, Arun wrote:
> Hi,
>
> I am working on a feature to implement support for gem objects to have
> variable size and realized a problem with the current implementation.
> Please advice me how to handle this situation efficiently.
>
> In this implementation the backing store of the object is replaced with
> scratch pages according to input range; Initially I store table entries in
> an array, replace relevant entries with scratch pages and I am using
> sg_alloc_table_from_pages() to create new sg_table which is assigned to the
> object. This implementation works as expected but I realized it is wasting
> memory as scratch page count increases.
>
> Consider the worst case scenario where all pages are replaced with scratch
> pages.
>
> The fn sg_alloc_table_from_pages() first computes the number of chunks based
> on the page frame numbers. PFNs that are consecutive form a chunk and it
> allocates scatterlists for each chunk which form the sg_table.
>
> In case of scratch pages they get the same pfn for each page and
> sg_alloc_table_from_pages() considers them not part of a chunk and it
> allocates scatterlist structure for each scratch page which takes lot of
> memory as the object size increases.
>
> I have to tried to modify sg_alloc_table_from_pages() implementation to
> check for scratch pfn and consider them as single chunk but after the update
> when iterating through for_each_sg_page() I am seeing different page
> addresses instead of all pointing to scratch page.
>
> Eg. In an object of size 8 pages, scratch_page = ffffea0001120000 and pfn:
> 0x00044800, the result I get is,
>
> page[0]: ffffea0001120000, pfn: 0x00044800,
> page[1]: ffffea0001120040, pfn: 0x00044801,
> page[2]: ffffea0001120080, pfn: 0x00044802,
> page[3]: ffffea00011200c0, pfn: 0x00044803,
> page[4]: ffffea0001120100, pfn: 0x00044804,
> page[5]: ffffea0001120140, pfn: 0x00044805,
> page[6]: ffffea0001120180, pfn: 0x00044806,
> page[7]: ffffea00011201c0, pfn: 0x00044807,
>
> How to manage multiple pages that have same pfn with a single scatterlist
> and still have it's length equal to (PAGE_SIZE*chunk_size)?
>
> I would really appreciate any suggestions to improve this implementation.
sg tables don't have the idea of repeating a given page, since it doesn't
make a lot of sense. Is the memory overhead really a big problem?
Extending the sg implementation with a flag somewhere to repeat a given
page instead of incrementing might be possible. But will be a bit of
effort to push that through the process since we'll touch code outside of
drm.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-06-12 7:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-11 23:49 [RFC] manage multiple entries of scratch page with scatterlist Siluvery, Arun
2014-06-12 7:26 ` Daniel Vetter [this message]
2014-06-12 11:36 ` Siluvery, Arun
2014-06-12 11:49 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140612072602.GU5821@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=arun.siluvery@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox