From: Knut Petersen <Knut_Petersen@t-online.de>
To: Linux MM <linux-mm@kvack.org>, Rik van Riel <riel@redhat.com>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Johannes Weiner <hannes@cmpxchg.org>,
LKML <linux-kernel@vger.kernel.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
Michal Hocko <mhocko@suse.cz>, Mel Gorman <mgorman@suse.de>,
Glauber Costa <glommer@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [Intel-gfx] [PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit
Date: Wed, 18 Sep 2013 13:34:23 +0200 [thread overview]
Message-ID: <52398FBF.5060102@t-online.de> (raw)
In-Reply-To: <20130918105631.GS32145@phenom.ffwll.local>
> 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 think that's the intention behind SHRINK_STOP. But if it's the
> right think to do we better revert the offending commit directly.
But there is other code that also returns SHRINK_STOP. So i believe it´s better to
adapt shrink_slab_node() to handle SHRINK_STOP properly than to revert 81e49f.
> And since I lack clue I think that's a call for core mm guys to make.
I agree. They´ll probably have to apply some additional changes to
shrink_slab_node(). It really doesn´t look right to me, but they certainly
know better what the code is supposed to do ;-)
cu,
Knut
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Knut Petersen <Knut_Petersen@t-online.de>
To: Linux MM <linux-mm@kvack.org>, Rik van Riel <riel@redhat.com>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Johannes Weiner <hannes@cmpxchg.org>,
LKML <linux-kernel@vger.kernel.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
Michal Hocko <mhocko@suse.cz>, Mel Gorman <mgorman@suse.de>,
Glauber Costa <glommer@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [Intel-gfx] [PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit
Date: Wed, 18 Sep 2013 13:34:23 +0200 [thread overview]
Message-ID: <52398FBF.5060102@t-online.de> (raw)
In-Reply-To: <20130918105631.GS32145@phenom.ffwll.local>
> 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 think that's the intention behind SHRINK_STOP. But if it's the
> right think to do we better revert the offending commit directly.
But there is other code that also returns SHRINK_STOP. So i believe it's better to
adapt shrink_slab_node() to handle SHRINK_STOP properly than to revert 81e49f.
> And since I lack clue I think that's a call for core mm guys to make.
I agree. They'll probably have to apply some additional changes to
shrink_slab_node(). It really doesn't look right to me, but they certainly
know better what the code is supposed to do ;-)
cu,
Knut
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Knut Petersen <Knut_Petersen@t-online.de>
To: Linux MM <linux-mm@kvack.org>, Rik van Riel <riel@redhat.com>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Johannes Weiner <hannes@cmpxchg.org>,
LKML <linux-kernel@vger.kernel.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
Michal Hocko <mhocko@suse.cz>, Mel Gorman <mgorman@suse.de>,
Glauber Costa <glommer@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [Intel-gfx] [PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit
Date: Wed, 18 Sep 2013 13:34:23 +0200 [thread overview]
Message-ID: <52398FBF.5060102@t-online.de> (raw)
In-Reply-To: <20130918105631.GS32145@phenom.ffwll.local>
> 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 think that's the intention behind SHRINK_STOP. But if it's the
> right think to do we better revert the offending commit directly.
But there is other code that also returns SHRINK_STOP. So i believe it´s better to
adapt shrink_slab_node() to handle SHRINK_STOP properly than to revert 81e49f.
> And since I lack clue I think that's a call for core mm guys to make.
I agree. They´ll probably have to apply some additional changes to
shrink_slab_node(). It really doesn´t look right to me, but they certainly
know better what the code is supposed to do ;-)
cu,
Knut
next prev parent reply other threads:[~2013-09-18 11:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-18 9:10 [PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit Daniel Vetter
2013-09-18 9:10 ` Daniel Vetter
2013-09-18 10:38 ` [Intel-gfx] " Knut Petersen
2013-09-18 10:38 ` Knut Petersen
2013-09-18 10:56 ` Daniel Vetter
2013-09-18 10:56 ` Daniel Vetter
2013-09-18 10:56 ` Daniel Vetter
2013-09-18 11:34 ` Knut Petersen [this message]
2013-09-18 11:34 ` Knut Petersen
2013-09-18 11:34 ` Knut Petersen
2013-09-18 20:38 ` Dave Chinner
2013-09-18 20:38 ` Dave Chinner
2013-09-18 20:38 ` Dave Chinner
2013-09-18 23:52 ` Dave Chinner
2013-09-18 23:52 ` Dave Chinner
2013-09-18 23:52 ` Dave Chinner
2013-09-19 6:57 ` Daniel Vetter
2013-09-19 6:57 ` Daniel Vetter
2013-09-19 7:32 ` Dave Chinner
2013-09-19 7:32 ` Dave Chinner
2013-09-19 8:04 ` Knut Petersen
2013-09-19 8:04 ` Knut Petersen
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=52398FBF.5060102@t-online.de \
--to=knut_petersen@t-online.de \
--cc=akpm@linux-foundation.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=glommer@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=riel@redhat.com \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.