linux-kernel - Re: [PATCH 3/3] Provide control over unmapped pages (v2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101223083354.GB16046@balbir.in.ibm.com>
Date:	Thu, 23 Dec 2010 14:03:54 +0530
From:	Balbir Singh <balbir@...ux.vnet.ibm.com>
To:	Minchan Kim <minchan.kim@...il.com>
Cc:	linux-mm@...ck.org, akpm@...ux-foundation.org, npiggin@...nel.dk,
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	kosaki.motohiro@...fujitsu.com, cl@...ux.com,
	kamezawa.hiroyu@...fujitsu.com
Subject: Re: [PATCH 3/3] Provide control over unmapped pages (v2)

* MinChan Kim <minchan.kim@...il.com> [2010-12-14 20:02:45]:

> > +                       if (should_reclaim_unmapped_pages(zone))
> > +                               wakeup_kswapd(zone, order);
> 
> I think we can put the logic into zone_watermark_okay.
>

I did some checks and zone_watermark_ok is used in several places for
a generic check like this -- for example prior to zone_reclaim(), if
in get_page_from_freelist() we skip zones based on the return value.
The compaction code uses it as well, the impact would be deeper. The
compaction code uses it to check whether an allocation will succeed or
not, I don't want unmapped page control to impact that.
 
> > +                       /*
> > +                        * We do unmapped page reclaim once here and once
> > +                        * below, so that we don't lose out
> > +                        */
> > +                       reclaim_unmapped_pages(priority, zone, &sc);
> 
> It can make unnecessary stir of lru pages.
> How about this?
> zone_watermark_ok returns ZONE_UNMAPPED_PAGE_FULL.
> wakeup_kswapd(..., please reclaim unmapped page cache).
> If kswapd is woke up by unmapped page full, kswapd sets up sc with unmap = 0.
> If the kswapd try to reclaim unmapped page, shrink_page_list doesn't
> rotate non-unmapped pages.

With may_unmap set to 0 and may_writepage set to 0, I don't think this
should be a major problem, like I said this code is already enabled if
zone_reclaim_mode != 0 and CONFIG_NUMA is set.

> > +unsigned long reclaim_unmapped_pages(int priority, struct zone *zone,
> > +                                               struct scan_control *sc)
> > +{
> > +       if (unlikely(unmapped_page_control) &&
> > +               (zone_unmapped_file_pages(zone) > zone->min_unmapped_pages)) {
> > +               struct scan_control nsc;
> > +               unsigned long nr_pages;
> > +
> > +               nsc = *sc;
> > +
> > +               nsc.swappiness = 0;
> > +               nsc.may_writepage = 0;
> > +               nsc.may_unmap = 0;
> > +               nsc.nr_reclaimed = 0;
> 
> This logic can be put in zone_reclaim_unmapped_pages.
> 

Now that I refactored the code and called it zone_reclaim_pages, I
expect the correct sc to be passed to it. This code is reused between
zone_reclaim() and reclaim_unmapped_pages(). In the former,
zone_reclaim does the setup.

> If we want really this, how about the new cache lru idea as Kame suggests?
> For example, add_to_page_cache_lru adds the page into cache lru.
> page_add_file_rmap moves the page into inactive file.
> page_remove_rmap moves the page into lru cache, again.
> We can count the unmapped pages and if the size exceeds limit, we can
> wake up kswapd.
> whenever the memory pressure happens, first of all, reclaimer try to
> reclaim cache lru.

We already have a file LRU and that has active/inactive lists, I don't
think a special mapped/unmapped list makes sense at this point.


-- 
	Three Cheers,
	Balbir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/