Messages in this thread | | | Date | Wed, 9 Jan 2013 16:26:02 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH 2/2] mm: forcely swapout when we are out of page cache |
| |
On Wed, 9 Jan 2013 15:21:14 +0900 Minchan Kim <minchan@kernel.org> wrote:
> If laptop_mode is enable, VM try to avoid I/O for saving the power. > But if there isn't reclaimable memory without I/O, we should do I/O > for preventing unnecessary OOM kill although we sacrifices power. > > One of example is that we are out of page cache. Remained one is > only anonymous pages, for swapping out, we needs may_writepage = 1. > > Reported-by: Luigi Semenzato <semenzato@google.com> > Signed-off-by: Minchan Kim <minchan@kernel.org> > --- > mm/vmscan.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 439cc47..624c816 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1728,6 +1728,12 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, > free = zone_page_state(zone, NR_FREE_PAGES); > if (unlikely(file + free <= high_wmark_pages(zone))) { > scan_balance = SCAN_ANON; > + /* > + * From now on, we have to swap out > + * for peventing OOM kill although > + * we sacrifice power consumption. > + */ > + sc->may_writepage = 1; > goto out; > } > }
This is pretty ugly. get_scan_count() is, as its name implies, an idempotent function which inspects the state of things and returns a result. As such, it has no business going in and altering the state of the scan_control.
We have code in both direct reclaim and in kswapd to set may_writepage if vmscan is getting into trouble. I don't see why adding another instance is necessary if the existing instances are working correctly.
(Is it correct that __zone_reclaim() ignores laptop_mode?)
I have a feeling that laptop mode has bitrotted and these patches are kinda hacking around as-yet-not-understood failures...
| |