Re: [RFC 0/3] Add new ioctl to resize gem object for deferred allocation

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

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@linux.intel.com wrote:
>>> From: "Siluvery, Arun" <arun.siluvery@intel.com>
>>>
>>> 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