* [PATCH] vmscan: recalculate lru_pages on each priority
@ 2010-06-25 9:13 KOSAKI Motohiro
2010-06-25 14:15 ` Rik van Riel
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: KOSAKI Motohiro @ 2010-06-25 9:13 UTC (permalink / raw)
To: LKML, linux-mm, Andrew Morton, Rik van Riel, Johannes Weiner,
Minchan Kim
Cc: kosaki.motohiro
shrink_zones() need relatively long time. and lru_pages can be
changed dramatically while shrink_zones().
then, lru_pages need recalculate on each priority.
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
---
mm/vmscan.c | 21 ++++++++-------------
1 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 0c961f1..0ebfe12 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1785,7 +1785,6 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
bool all_unreclaimable;
unsigned long total_scanned = 0;
struct reclaim_state *reclaim_state = current->reclaim_state;
- unsigned long lru_pages = 0;
struct zoneref *z;
struct zone *zone;
enum zone_type high_zoneidx = gfp_zone(sc->gfp_mask);
@@ -1796,18 +1795,6 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
if (scanning_global_lru(sc))
count_vm_event(ALLOCSTALL);
- /*
- * mem_cgroup will not do shrink_slab.
- */
- if (scanning_global_lru(sc)) {
- for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
-
- if (!cpuset_zone_allowed_hardwall(zone, GFP_KERNEL))
- continue;
-
- lru_pages += zone_reclaimable_pages(zone);
- }
- }
for (priority = DEF_PRIORITY; priority >= 0; priority--) {
sc->nr_scanned = 0;
@@ -1819,6 +1806,14 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
* over limit cgroups
*/
if (scanning_global_lru(sc)) {
+ unsigned long lru_pages = 0;
+ for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
+ if (!cpuset_zone_allowed_hardwall(zone, GFP_KERNEL))
+ continue;
+
+ lru_pages += zone_reclaimable_pages(zone);
+ }
+
shrink_slab(sc->nr_scanned, sc->gfp_mask, lru_pages);
if (reclaim_state) {
sc->nr_reclaimed += reclaim_state->reclaimed_slab;
--
1.6.5.2
--
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>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] vmscan: recalculate lru_pages on each priority
2010-06-25 9:13 [PATCH] vmscan: recalculate lru_pages on each priority KOSAKI Motohiro
@ 2010-06-25 14:15 ` Rik van Riel
2010-06-26 23:33 ` Minchan Kim
2010-06-27 11:34 ` Johannes Weiner
2 siblings, 0 replies; 5+ messages in thread
From: Rik van Riel @ 2010-06-25 14:15 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: LKML, linux-mm, Andrew Morton, Johannes Weiner, Minchan Kim
On 06/25/2010 05:13 AM, KOSAKI Motohiro wrote:
> shrink_zones() need relatively long time. and lru_pages can be
> changed dramatically while shrink_zones().
> then, lru_pages need recalculate on each priority.
>
> Signed-off-by: KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com>
Acked-by: Rik van Riel <riel@redhat.com>
--
All rights reversed
--
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>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] vmscan: recalculate lru_pages on each priority
2010-06-25 9:13 [PATCH] vmscan: recalculate lru_pages on each priority KOSAKI Motohiro
2010-06-25 14:15 ` Rik van Riel
@ 2010-06-26 23:33 ` Minchan Kim
2010-06-27 11:34 ` Johannes Weiner
2 siblings, 0 replies; 5+ messages in thread
From: Minchan Kim @ 2010-06-26 23:33 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: LKML, linux-mm, Andrew Morton, Rik van Riel, Johannes Weiner
On Fri, Jun 25, 2010 at 6:13 PM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
> shrink_zones() need relatively long time. and lru_pages can be
> changed dramatically while shrink_zones().
> then, lru_pages need recalculate on each priority.
>
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Kosaki's patch seems to be reasonable to me.
I looked into background reclaim. It already has done until now.
(ie, background : dynamic lru_pages in each priority, direct reclaim :
static lru_pages in each priority).
Firstly In 53dce00d, Andrew did it.
Why does he do it with unbalance?
I guess it was just a mistake.
--
Kind regards,
Minchan Kim
--
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>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] vmscan: recalculate lru_pages on each priority
2010-06-25 9:13 [PATCH] vmscan: recalculate lru_pages on each priority KOSAKI Motohiro
2010-06-25 14:15 ` Rik van Riel
2010-06-26 23:33 ` Minchan Kim
@ 2010-06-27 11:34 ` Johannes Weiner
2010-06-28 1:39 ` KOSAKI Motohiro
2 siblings, 1 reply; 5+ messages in thread
From: Johannes Weiner @ 2010-06-27 11:34 UTC (permalink / raw)
To: KOSAKI Motohiro; +Cc: LKML, linux-mm, Andrew Morton, Rik van Riel, Minchan Kim
On Fri, Jun 25, 2010 at 06:13:20PM +0900, KOSAKI Motohiro wrote:
> shrink_zones() need relatively long time. and lru_pages can be
> changed dramatically while shrink_zones().
> then, lru_pages need recalculate on each priority.
In the direct reclaim path, we bail out of that loop after
SWAP_CLUSTER_MAX reclaimed pages, so in this case, decreasing priority
levels actually mean we do _not_ make any progress and the total
number of lru pages should not change (much). The possible distortion
in shrink_slab() is small.
However, for the suspend-to-disk case the reclaim target can be a lot
higher and we inevitably end up at higher priorities even though we
make progress, but fail to increase pressure on the shrinkers as well
without your patch.
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
--
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>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] vmscan: recalculate lru_pages on each priority
2010-06-27 11:34 ` Johannes Weiner
@ 2010-06-28 1:39 ` KOSAKI Motohiro
0 siblings, 0 replies; 5+ messages in thread
From: KOSAKI Motohiro @ 2010-06-28 1:39 UTC (permalink / raw)
To: Johannes Weiner
Cc: kosaki.motohiro, LKML, linux-mm, Andrew Morton, Rik van Riel,
Minchan Kim
> On Fri, Jun 25, 2010 at 06:13:20PM +0900, KOSAKI Motohiro wrote:
> > shrink_zones() need relatively long time. and lru_pages can be
> > changed dramatically while shrink_zones().
> > then, lru_pages need recalculate on each priority.
>
> In the direct reclaim path, we bail out of that loop after
> SWAP_CLUSTER_MAX reclaimed pages, so in this case, decreasing priority
> levels actually mean we do _not_ make any progress and the total
> number of lru pages should not change (much). The possible distortion
> in shrink_slab() is small.
Oh, you seems forgot the case when much thread enter try_to_free_pages()
concurrently.
>
> However, for the suspend-to-disk case the reclaim target can be a lot
> higher and we inevitably end up at higher priorities even though we
> make progress, but fail to increase pressure on the shrinkers as well
> without your patch.
>
> Acked-by: Johannes Weiner <hannes@cmpxchg.org>
--
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>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-06-28 1:39 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-25 9:13 [PATCH] vmscan: recalculate lru_pages on each priority KOSAKI Motohiro
2010-06-25 14:15 ` Rik van Riel
2010-06-26 23:33 ` Minchan Kim
2010-06-27 11:34 ` Johannes Weiner
2010-06-28 1:39 ` KOSAKI Motohiro
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox