From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Siluvery, Arun" <arun.siluvery@linux.intel.com>
Subject: Re: [RFC 0/3] Add new ioctl to resize gem object for
 deferred allocation
Date: Fri, 04 Apr 2014 11:45:15 +0100
Message-ID: <533E8D3B.9070806@linux.intel.com>
References: <1395934109-28522-1-git-send-email-arun.siluvery@linux.intel.com>
 <20140327222314.GA16117@nuc-i3427.alporthouse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
 by gabe.freedesktop.org (Postfix) with ESMTP id E40C189D39
 for <intel-gfx@lists.freedesktop.org>; Fri,  4 Apr 2014 03:45:23 -0700 (PDT)
In-Reply-To: <20140327222314.GA16117@nuc-i3427.alporthouse.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: intel-gfx-bounces@lists.freedesktop.org
Sender: "Intel-gfx" <intel-gfx-bounces@lists.freedesktop.org>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

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
>
Sorry for the delayed response, I was on holiday. I will modify the 
implementation to use fallocate(), shmem is supporting this and it seems 
to be a better approach.
In this case once the object is created we extend gem_create ioctl using 
fallocate() and allocate the additional space but does the userspace 
still see it as a contiguous block when it writes to the additional space?
Once the object is modified using fallocate(), are these changes 
completely transparent when this object is used in other functions?
please clarify.

regards
Arun