From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Siluvery, Arun" Subject: Re: [RFC] manage multiple entries of scratch page with scatterlist Date: Thu, 12 Jun 2014 12:36:20 +0100 Message-ID: <539990B4.2000607@linux.intel.com> References: <5398EB1B.6070208@linux.intel.com> <20140612072602.GU5821@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTP id 99B706E90E for ; Thu, 12 Jun 2014 04:36:22 -0700 (PDT) In-Reply-To: <20140612072602.GU5821@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: "intel-gfx@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org On 12/06/2014 08:26, Daniel Vetter wrote: > 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? > One other use case where it can be useful is for the creation of blanking buffer. Considering a frame buffer size of 8MB = 2K pages, each scatterlist is 32 bytes which takes 64K for an 8MB object. I think this overhead is acceptable which also simplifies the implementation. > 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. I will explore this option if we see any issues with the overhead. Thank you for your comments. regards Arun > -Daniel >