Messages in this thread Patch in this message | | | From | KOSAKI Motohiro <> | Subject | Re: [PATCH]vmscan: handle underflow for get_scan_ratio | Date | Tue, 30 Mar 2010 16:31:40 +0900 (JST) |
| |
> > > > Very unfortunately, this patch isn't acceptable. In past time, vmscan > > > > had similar logic, but 1% swap-out made lots bug reports. > > > can you elaborate this? > > > Completely restore previous behavior (do full scan with priority 0) is > > > ok too. > > > > This is a option. but we need to know the root cause anyway. > I thought I mentioned the root cause in first mail. My debug shows > recent_rotated[0] is big, but recent_rotated[1] is almost zero, which makes > percent[0] 0. But you can double check too.
To revert can save percent[0]==0 && priority==0 case. but it shouldn't happen, I think. It mean to happen big latency issue.
Can you please try following patch? Also, I'll prepare reproduce environment soon.
--- mm/vmscan.c | 12 ++++++++---- 1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c index 79c8098..abf7f79 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1571,15 +1571,19 @@ static void get_scan_ratio(struct zone *zone, struct scan_control *sc, */ if (unlikely(reclaim_stat->recent_scanned[0] > anon / 4)) { spin_lock_irq(&zone->lru_lock); - reclaim_stat->recent_scanned[0] /= 2; - reclaim_stat->recent_rotated[0] /= 2; + while (reclaim_stat->recent_scanned[0] > anon / 4) { + reclaim_stat->recent_scanned[0] /= 2; + reclaim_stat->recent_rotated[0] /= 2; + } spin_unlock_irq(&zone->lru_lock); } if (unlikely(reclaim_stat->recent_scanned[1] > file / 4)) { spin_lock_irq(&zone->lru_lock); - reclaim_stat->recent_scanned[1] /= 2; - reclaim_stat->recent_rotated[1] /= 2; + while (reclaim_stat->recent_scanned[1] > file / 4) { + reclaim_stat->recent_scanned[1] /= 2; + reclaim_stat->recent_rotated[1] /= 2; + } spin_unlock_irq(&zone->lru_lock); } -- 1.6.5.2
| |