On Fri, Feb 18, 2011 at 12:50 AM, KAMEZAWA Hiroyuki
[off-list ref] wrote:

quoted

On Fri, 18 Feb 2011 00:08:19 +0900
Minchan Kim [off-list ref] wrote:

quoted

Recently, there are reported problem about thrashing.
(http://marc.info/?l=rsync&m=128885034930933&w=2)
It happens by backup workloads(ex, nightly rsync).
That's because the workload makes just use-once pages
and touches pages twice. It promotes the page into
active list so that it results in working set page eviction.

Some app developer want to support POSIX_FADV_NOREUSE.
But other OSes don't support it, either.
(http://marc.info/?l=linux-mm&m=128928979512086&w=2)

By other approach, app developers use POSIX_FADV_DONTNEED.
But it has a problem. If kernel meets page is writing
during invalidate_mapping_pages, it can't work.
It makes for application programmer to use it since they always
have to sync data before calling fadivse(..POSIX_FADV_DONTNEED) to
make sure the pages could be discardable. At last, they can't use
deferred write of kernel so that they could see performance loss.
(http://insights.oetiker.ch/linux/fadvise.html)

In fact, invalidation is very big hint to reclaimer.
It means we don't use the page any more. So let's move
the writing page into inactive list's head if we can't truncate
it right now.

Why I move page to head of lru on this patch, Dirty/Writeback page
would be flushed sooner or later. It can prevent writeout of pageout
which is less effective than flusher's writeout.

Originally, I reused lru_demote of Peter with some change so added
his Signed-off-by.

Reported-by: Ben Gamari <redacted>
Signed-off-by: Minchan Kim <redacted>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Rik van Riel <redacted>
Acked-by: Mel Gorman <redacted>
Reviewed-by: KOSAKI Motohiro <redacted>
Cc: Wu Fengguang <redacted>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Nick Piggin <redacted>
Signed-off-by: Minchan Kim <redacted>

Reviewed-by: KAMEZAWA Hiroyuki <redacted>

One question is ....it seems there is no flush() code for percpu pagevec
in this patch. Is it safe against cpu hot plug ?

And from memory hot unplug point of view, I'm grad if pagevec for this
is flushed at the same time as when we clear other per-cpu lru pagevecs.
(And compaction will be affected by the page_count() magic by pagevec
 which is flushed only when FADVISE is called.)

Could you add add-on patches for flushing and hooks ?

Isn't it enough in my patch? If I miss your point, Could you elaborate please?

 * Drain pages out of the cpu's pagevecs.
 * Either "cpu" is the current CPU, and preemption has already been
 * disabled; or "cpu" is being hot-unplugged, and is already dead.

@@ -372,6 +427,29 @@ static void drain_cpu_pagevecs(int cpu)

              pagevec_move_tail(pvec);
              local_irq_restore(flags);
      }
+
+       pvec = &per_cpu(lru_deactivate_pvecs, cpu);
+       if (pagevec_count(pvec))
+               ____pagevec_lru_deactivate(pvec);
+}