On Fri, Aug 16, 2013 at 12:24:37PM +0100, Chris Wilson wrote:
> The primary purpose of this list is for pretty printing the maps through
> debugfs/vma - per process information can be found in /proc/*/map et al.
> However, the list manipulation eats processor cycles resulting in a near
> indefinite
On Fri, Aug 16, 2013 at 12:24:37PM +0100, Chris Wilson wrote:
> The primary purpose of this list is for pretty printing the maps through
> debugfs/vma - per process information can be found in /proc/*/map et al.
> However, the list manipulation eats processor cycles resulting in a near
> indefinite
Hi
On Fri, Aug 16, 2013 at 1:24 PM, Chris Wilson
wrote:
> The primary purpose of this list is for pretty printing the maps through
> debugfs/vma - per process information can be found in /proc/*/map et al.
> However, the list manipulation eats processor cycles resulting in a near
> indefinite (I
Hi
On Fri, Aug 16, 2013 at 1:24 PM, Chris Wilson wrote:
> The primary purpose of this list is for pretty printing the maps through
> debugfs/vma - per process information can be found in /proc/*/map et al.
> However, the list manipulation eats processor cycles resulting in a near
> indefinite (I
The primary purpose of this list is for pretty printing the maps through
debugfs/vma - per process information can be found in /proc/*/map et al.
However, the list manipulation eats processor cycles resulting in a near
indefinite (I got bored) stall for a leaky i-g-t/gem_concurrent_blit.
There is
The primary purpose of this list is for pretty printing the maps through
debugfs/vma - per process information can be found in /proc/*/map et al.
However, the list manipulation eats processor cycles resulting in a near
indefinite (I got bored) stall for a leaky i-g-t/gem_concurrent_blit.
There is
