On 19.09.2013 08:57, Daniel Vetter wrote:
On Wed, Sep 18, 2013 at 10:38 PM, Dave Chinner wrote:
No, that's wrong. ->count_objects should never ass SHRINK_STOP.
Indeed, it should always return a count of objects in the cache,
regardless of the context.
SHRINK_STOP is for ->scan_objects to tell
On Thu, Sep 19, 2013 at 08:57:04AM +0200, Daniel Vetter wrote:
> On Wed, Sep 18, 2013 at 10:38 PM, Dave Chinner wrote:
> > No, that's wrong. ->count_objects should never ass SHRINK_STOP.
> > Indeed, it should always return a count of objects in the cache,
> > regardless of the context.
> >
> >
On Wed, Sep 18, 2013 at 10:38 PM, Dave Chinner wrote:
> No, that's wrong. ->count_objects should never ass SHRINK_STOP.
> Indeed, it should always return a count of objects in the cache,
> regardless of the context.
>
> SHRINK_STOP is for ->scan_objects to tell the shrinker it can make
> any
On Wed, Sep 18, 2013 at 10:38 PM, Dave Chinner da...@fromorbit.com wrote:
No, that's wrong. -count_objects should never ass SHRINK_STOP.
Indeed, it should always return a count of objects in the cache,
regardless of the context.
SHRINK_STOP is for -scan_objects to tell the shrinker it can
On Thu, Sep 19, 2013 at 08:57:04AM +0200, Daniel Vetter wrote:
On Wed, Sep 18, 2013 at 10:38 PM, Dave Chinner da...@fromorbit.com wrote:
No, that's wrong. -count_objects should never ass SHRINK_STOP.
Indeed, it should always return a count of objects in the cache,
regardless of the context.
On 19.09.2013 08:57, Daniel Vetter wrote:
On Wed, Sep 18, 2013 at 10:38 PM, Dave Chinner da...@fromorbit.com wrote:
No, that's wrong. -count_objects should never ass SHRINK_STOP.
Indeed, it should always return a count of objects in the cache,
regardless of the context.
SHRINK_STOP is for
[my keyboard my be on the fritz - it's not typing what I'm thinking...]
On Thu, Sep 19, 2013 at 06:38:22AM +1000, Dave Chinner wrote:
> On Wed, Sep 18, 2013 at 12:38:23PM +0200, Knut Petersen wrote:
> > On 18.09.2013 11:10, Daniel Vetter wrote:
> >
> > Just now I prepared a patch changing the
On Wed, Sep 18, 2013 at 12:38:23PM +0200, Knut Petersen wrote:
> On 18.09.2013 11:10, Daniel Vetter wrote:
>
> Just now I prepared a patch changing the same function in vmscan.c
> >Also, this needs to be rebased to the new shrinker api in 3.12, I
> >simply haven't rolled my trees forward yet.
>
Looking at the patch which introduced these error message for you, which
changed the ->count_objects return value from 0 to SHRINK_STOP your patch
below to treat 0 and SHRINK_STOP equally simply reverts the functional
change.
Yes, for i915* it de facto restores the old behaviour.
I don't
On Wed, Sep 18, 2013 at 12:38:23PM +0200, Knut Petersen wrote:
> On 18.09.2013 11:10, Daniel Vetter wrote:
>
> Just now I prepared a patch changing the same function in vmscan.c
> >Also, this needs to be rebased to the new shrinker api in 3.12, I
> >simply haven't rolled my trees forward yet.
>
On 18.09.2013 11:10, Daniel Vetter wrote:
Just now I prepared a patch changing the same function in vmscan.c
Also, this needs to be rebased to the new shrinker api in 3.12, I
simply haven't rolled my trees forward yet.
Well, you should. Since commit 81e49f shrinker->count_objects might be
The drm/i915 gpu driver loves to hang onto as much memory as it can -
we cache pinned pages, dma mappings and obviously also gpu address
space bindings of buffer objects. On top of that userspace has its own
opportunistic cache which is managed by an madvise-like ioctl to tell
the kernel which
The drm/i915 gpu driver loves to hang onto as much memory as it can -
we cache pinned pages, dma mappings and obviously also gpu address
space bindings of buffer objects. On top of that userspace has its own
opportunistic cache which is managed by an madvise-like ioctl to tell
the kernel which
On 18.09.2013 11:10, Daniel Vetter wrote:
Just now I prepared a patch changing the same function in vmscan.c
Also, this needs to be rebased to the new shrinker api in 3.12, I
simply haven't rolled my trees forward yet.
Well, you should. Since commit 81e49f shrinker-count_objects might be
set
On Wed, Sep 18, 2013 at 12:38:23PM +0200, Knut Petersen wrote:
On 18.09.2013 11:10, Daniel Vetter wrote:
Just now I prepared a patch changing the same function in vmscan.c
Also, this needs to be rebased to the new shrinker api in 3.12, I
simply haven't rolled my trees forward yet.
Well,
Looking at the patch which introduced these error message for you, which
changed the -count_objects return value from 0 to SHRINK_STOP your patch
below to treat 0 and SHRINK_STOP equally simply reverts the functional
change.
Yes, for i915* it de facto restores the old behaviour.
I don't
On Wed, Sep 18, 2013 at 12:38:23PM +0200, Knut Petersen wrote:
On 18.09.2013 11:10, Daniel Vetter wrote:
Just now I prepared a patch changing the same function in vmscan.c
Also, this needs to be rebased to the new shrinker api in 3.12, I
simply haven't rolled my trees forward yet.
Well,
[my keyboard my be on the fritz - it's not typing what I'm thinking...]
On Thu, Sep 19, 2013 at 06:38:22AM +1000, Dave Chinner wrote:
On Wed, Sep 18, 2013 at 12:38:23PM +0200, Knut Petersen wrote:
On 18.09.2013 11:10, Daniel Vetter wrote:
Just now I prepared a patch changing the same
18 matches
Mail list logo
