On 04/07/2014 02:18 PM, Siluvery, Arun wrote:
On 27/03/2014 22:23, Chris Wilson wrote:
On Thu, Mar 27, 2014 at 03:28:26PM +0000,
arun.siluvery@xxxxxxxxxxxxxxx wrote:
From: "Siluvery, Arun" <arun.siluvery@xxxxxxxxx>
This patch series adds a new ioctl to resize a gem object.
I'm tired, but off the top of my head, I think you can do away with the
magic extension to create_ioctl. If we allow any one to fallocate()
ranges of any object, the user can create a large object, populate it
all with a scratch page, then later populate regions as required. This
looks quite a reasonable and useful feature.
-Chris
Could you clarify my understanding on how to use fallocate() to resize
the object, considering the case where we start with an object of size x
and want to increase its size to (x+y) at a later point.
My understanding is, first object is created with gem_create ioctl with
size x. At a later point if it is to be resized, we allocate y at the
end of x using fallocate(). It is allocating the pages for us and from
its implementation it is clear that the file size is updated with new
value if offset+len is greater than initial size.
Do we need to make any changes for GEM to get the new size or it is
completely transparent to it?
could you give an overview on how you think it should work?
My understanding of what Chris said is that fallocate(2) could be used
to toggle ranges of an object - from "normal" backing store, to scratch
page backing store.
There is a mode argument passed in to fallocate, so if that is zero you
could populate the passed in range with scratch pages. Or if mode is
FALLOC_FL_KEEP_SIZE you could allocate proper backing.
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
