On Tue, 2014-05-06 at 11:34 +0000, Chris Wilson wrote: > On Tue, May 06, 2014 at 04:40:58PM +0530, sourab.gupta@xxxxxxxxx wrote: > > From: Sourab Gupta <sourab.gupta@xxxxxxxxx> > > > > This patch is in continuation of and is dependent on earlier patch > > series to 'reduce the time for which device mutex is kept locked'. > > (http://lists.freedesktop.org/archives/intel-gfx/2014-May/044596.html) > > > > This patch aims to reduce the allocation time of pages from shmem > > by using blitter engines for clearing the pages freshly alloced. > > This is utilized in case of fresh pages allocated in shmem_preallocate > > routines in execbuffer path and page_fault path only. > > > > Even though the CPU memset routine is optimized, but still sometimes > > the time consumed in clearing the pages of a large buffer comes in > > the order of milliseconds. > > We intend to make this operation asynchronous by using blitter engine, > > so irrespective of the size of buffer to be cleared, the execbuffer > > ioctl processing time will not be affected. Use of blitter engine will > > make the overall execution time of 'execbuffer' ioctl lesser for > > large buffers. > > > > There may be power implications here on using blitter engines, and > > we have to evaluate this. As a next step, we can selectively enable > > this HW based memset only for large buffers, where the overhead of > > adding commands in a blitter ring(which will otherwise be idle), > > cross ring synchronization, will be negligible compared to using the > > CPU to clear out the buffer. > > You leave a lot of holes by which you leak the uncleared pages to > userspace. > -Chris > Hi Chris, Are you ok with the overall design as such, and the shmem_read_mapping_page_gfp_noclear interface? Is the leak of uncleared pages happening due to implementation issues? If so, we'll try to mitigate them. Regards, Sourab _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
