Re: [RFC] drm/i915 : Reduce the shmem page allocation time by using blitter engines for clearing pages.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux