On 13.08.2014 12:52, Jérôme Glisse wrote:
> From: Jérôme Glisse <jglisse@xxxxxxxxxx>
>
> Due to bug in code it appear that some of the pool where never properly
> use and always empty. Before fixing that bug this patch set sensible
> limit on pool size. The magic 64MB number was nominated.
>
> This is obviously a some what arbitrary number but the intend of ttm pool
> is to minimize page alloc cost especialy when allocating page that will be
> mark to be excluded from cpu cache mecanisms. We assume that mostly small
> buffer that are constantly allocated/deallocated might suffer from core
> memory allocation overhead as well as cache status change. This are the
> assumptions behind the 64MB value.
>
> This obviously need some serious testing including monitoring pool size.
>
> Signed-off-by: Jérôme Glisse <jglisse@xxxxxxxxxx>
[...]
> @@ -393,8 +404,9 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
> pr_info("Zone %7s: Available graphics memory: %llu kiB\n",
> zone->name, (unsigned long long)zone->max_mem >> 10);
> }
> - ttm_page_alloc_init(glob, glob->zone_kernel->max_mem/(2*PAGE_SIZE));
> - ttm_dma_page_alloc_init(glob, glob->zone_kernel->max_mem/(2*PAGE_SIZE));
> + max_pool_size = min(glob->zone_kernel->max_mem >> 3UL, MAX_POOL_SIZE);
This introduces a 'comparison of distinct pointer types lacks a cast'
warning for me.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
