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 <[email protected]>
---
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
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<[email protected]>
Acked-by: Rik van Riel <[email protected]>
--
All rights reversed
On Fri, Jun 25, 2010 at 6:13 PM, KOSAKI Motohiro
<[email protected]> 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 <[email protected]>
Reviewed-by: Minchan Kim <[email protected]>
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
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 <[email protected]>
> 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 <[email protected]>