public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Siluvery, Arun" <arun.siluvery@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [RFC 0/3] Add new ioctl to resize gem object for deferred allocation
Date: Mon, 07 Apr 2014 14:18:22 +0100	[thread overview]
Message-ID: <5342A59E.3090205@linux.intel.com> (raw)
In-Reply-To: <20140327222314.GA16117@nuc-i3427.alporthouse.com>

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?

regards
Arun

  parent reply	other threads:[~2014-04-07 13:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-27 15:28 [RFC 0/3] Add new ioctl to resize gem object for deferred allocation arun.siluvery
2014-03-27 15:28 ` [RFC 1/3] drm/i915: Prepare gem object to handle resize arun.siluvery
2014-03-27 15:28 ` [RFC 2/3] drm/i915: Handle gem object resize using scratch page for lazy allocation arun.siluvery
2014-03-27 15:28 ` [RFC 3/3] drm/i915: Create new ioctl to request gem object resize arun.siluvery
2014-03-27 22:23 ` [RFC 0/3] Add new ioctl to resize gem object for deferred allocation Chris Wilson
2014-04-04 10:45   ` Siluvery, Arun
2014-04-07 13:18   ` Siluvery, Arun [this message]
2014-04-07 14:54     ` Tvrtko Ursulin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5342A59E.3090205@linux.intel.com \
    --to=arun.siluvery@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox