On Wed, 23 Nov 2016, Daniel Vetter wrote:
> On Tue, Nov 22, 2016 at 09:26:11PM -0800, Hugh Dickins wrote:
> > On Tue, 22 Nov 2016, Matthew Auld wrote:
> > > On 9 November 2016 at 18:36, Hugh Dickins wrote:
> > > > On Wed, 9 Nov 2016, Daniel Vetter wrote:
> > > >>
> > > >> Hi all
On Tue, Nov 22, 2016 at 09:26:11PM -0800, Hugh Dickins wrote:
> On Tue, 22 Nov 2016, Matthew Auld wrote:
> > On 9 November 2016 at 18:36, Hugh Dickins wrote:
> > > On Wed, 9 Nov 2016, Daniel Vetter wrote:
> > >>
> > >> Hi all -mm folks!
> > >>
> > >> Any feedback on these two?
On Tue, 22 Nov 2016, Matthew Auld wrote:
> On 9 November 2016 at 18:36, Hugh Dickins wrote:
> > On Wed, 9 Nov 2016, Daniel Vetter wrote:
> >>
> >> Hi all -mm folks!
> >>
> >> Any feedback on these two? It's kinda an intermediate step towards a
> >> full-blown gemfs, and I think
On 9 November 2016 at 18:36, Hugh Dickins wrote:
> On Wed, 9 Nov 2016, Daniel Vetter wrote:
>>
>> Hi all -mm folks!
>>
>> Any feedback on these two? It's kinda an intermediate step towards a
>> full-blown gemfs, and I think useful for that. Or do we need to go
>> directly to our
On Wed, Nov 16, 2016 at 6:55 AM, Hugh Dickins wrote:
> On Mon, 14 Nov 2016, akash goel wrote:
>> On Thu, Nov 10, 2016 at 1:00 PM, Goel, Akash wrote:
>> > On 11/10/2016 12:09 PM, Hugh Dickins wrote:
>> >> On Fri, 4 Nov 2016, akash.g...@intel.com wrote:
>>
On Mon, 14 Nov 2016, akash goel wrote:
> On Thu, Nov 10, 2016 at 1:00 PM, Goel, Akash wrote:
> > On 11/10/2016 12:09 PM, Hugh Dickins wrote:
> >> On Fri, 4 Nov 2016, akash.g...@intel.com wrote:
> >>> @@ -4185,6 +4189,8 @@ struct drm_i915_gem_object *
> >>>
> >>> mask
On Thu, Nov 10, 2016 at 1:00 PM, Goel, Akash wrote:
>
>
> On 11/10/2016 12:09 PM, Hugh Dickins wrote:
>>
>> On Fri, 4 Nov 2016, akash.g...@intel.com wrote:
>>>
>>> From: Chris Wilson
>>>
>>> On a long run of more than 2-3 days, physical memory
On 11/10/2016 12:09 PM, Hugh Dickins wrote:
On Fri, 4 Nov 2016, akash.g...@intel.com wrote:
From: Chris Wilson
On a long run of more than 2-3 days, physical memory tends to get
fragmented severely, which considerably slows down the system. In such a
scenario, the
On Fri, 4 Nov 2016, akash.g...@intel.com wrote:
> From: Chris Wilson
>
> On a long run of more than 2-3 days, physical memory tends to get
> fragmented severely, which considerably slows down the system. In such a
> scenario, the shrinker is also unable to help as lack
On Wed, 9 Nov 2016, Daniel Vetter wrote:
>
> Hi all -mm folks!
>
> Any feedback on these two? It's kinda an intermediate step towards a
> full-blown gemfs, and I think useful for that. Or do we need to go
> directly to our own backing storage thing? Aside from ack/nack from -mm I
> think this is
On Fri, Nov 04, 2016 at 08:32:56PM +0530, akash.g...@intel.com wrote:
> From: Chris Wilson
>
> On a long run of more than 2-3 days, physical memory tends to get
> fragmented severely, which considerably slows down the system. In such a
> scenario, the shrinker is also
From: Chris Wilson
On a long run of more than 2-3 days, physical memory tends to get
fragmented severely, which considerably slows down the system. In such a
scenario, the shrinker is also unable to help as lack of memory is not
the actual problem, since it has been
On 11/4/2016 7:07 PM, Chris Wilson wrote:
Best if we send these as a new series to unconfuse CI.
Okay will send as a new series.
On Fri, Nov 04, 2016 at 06:18:26PM +0530, akash.g...@intel.com wrote:
+static int do_migrate_page(struct drm_i915_gem_object *obj)
+{
+ struct
Best if we send these as a new series to unconfuse CI.
On Fri, Nov 04, 2016 at 06:18:26PM +0530, akash.g...@intel.com wrote:
> +static int do_migrate_page(struct drm_i915_gem_object *obj)
> +{
> + struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> + int ret = 0;
> +
> + if
From: Chris Wilson
On a long run of more than 2-3 days, physical memory tends to get
fragmented severely, which considerably slows down the system. In such a
scenario, the shrinker is also unable to help as lack of memory is not
the actual problem, since it has been
15 matches
Mail list logo