| Message ID | 20161223105157.GB23109@dhcp22.suse.cz (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On Fri, Dec 23, 2016 at 11:51:57AM +0100, Michal Hocko wrote: > TL;DR > drop the last patch, check whether memory cgroup is enabled and retest > with cgroup_disable=memory to see whether this is memcg related and if > it is _not_ then try to test with the patch below Right, it seems we might be looking in the right direction! So I removed the previous patch from my kernel and verified if memory cgroup was enabled, and indeed, it was. So I booted with cgroup_disable=memory and ran my ordinary test again ... and in fact, no ooms! I could have the firefox sources building and unpack half a dozen big tarballs, which would previously with 99% certainty already trigger an OOM upon unpacking the first tarball. Also, the system seemed to run noticably "nicer", in the sense that the other processes I had running (like htop) would not get delayed / hung. The new patch you sent has, as per your instructions, NOT been applied. I've provided a log of this run, it's available at: http://ftp.tisys.org/pub/misc/boerne_2016-12-23.log.xz As no OOMs or other bad situations occured, no memory information was forcibly logged. However, about three times I triggered a memory info manually via SysReq, because I guess that might be interesting for you to look at. I'd like to run the same test on my second machine as well just to make sure that cgroup_disable=memory has an effect there too. I should be able to do that later tonight and will report back as soon as I know more! > I would appreciate to stick with your setup to not pull new unknows into > the picture. No problem! It's just likely that I won't be able to test during the following days until Dec 27th, but after that I should be back to normal and thus be able to run further tests in a timely fashion. :-) Greetings Nils -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri 23-12-16 13:18:51, Nils Holland wrote: > On Fri, Dec 23, 2016 at 11:51:57AM +0100, Michal Hocko wrote: > > TL;DR > > drop the last patch, check whether memory cgroup is enabled and retest > > with cgroup_disable=memory to see whether this is memcg related and if > > it is _not_ then try to test with the patch below > > Right, it seems we might be looking in the right direction! So I > removed the previous patch from my kernel and verified if memory > cgroup was enabled, and indeed, it was. So I booted with > cgroup_disable=memory and ran my ordinary test again ... and in fact, > no ooms! OK, thanks for confirmation. I could have figured that earlier. The pagecache differences in such a short time should have raised the red flag and point towards memcgs... [...] > > I would appreciate to stick with your setup to not pull new unknows into > > the picture. > > No problem! It's just likely that I won't be able to test during the > following days until Dec 27th, but after that I should be back to > normal and thus be able to run further tests in a timely fashion. :-) no problem at all. I will try to cook up a patch in the mean time.
diff --git a/mm/vmscan.c b/mm/vmscan.c index cb82913b62bb..533bb591b0be 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -243,6 +243,35 @@ unsigned long lruvec_lru_size(struct lruvec *lruvec, enum lru_list lru) } /* + * Return the number of pages on the given lru which are eligibne for the + * given zone_idx + */ +static unsigned long lruvec_lru_size_zone_idx(struct lruvec *lruvec, + enum lru_list lru, int zone_idx) +{ + struct pglist_data *pgdat = lruvec_pgdat(lruvec); + unsigned long lru_size; + int zid; + + if (!mem_cgroup_disabled()) + return mem_cgroup_get_lru_size(lruvec, lru); + + lru_size = lruvec_lru_size(lruvec, lru); + for (zid = zone_idx + 1; zid < MAX_NR_ZONES; zid++) { + struct zone *zone = &pgdat->node_zones[zid]; + unsigned long size; + + if (!managed_zone(zone)) + continue; + + size = zone_page_state(zone, NR_ZONE_LRU_BASE + lru); + lru_size -= min(size, lru_size); + } + + return lru_size; +} + +/* * Add a shrinker callback to be called from the vm. */ int register_shrinker(struct shrinker *shrinker) @@ -2228,7 +2257,7 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg, * system is under heavy pressure. */ if (!inactive_list_is_low(lruvec, true, sc) && - lruvec_lru_size(lruvec, LRU_INACTIVE_FILE) >> sc->priority) { + lruvec_lru_size_zone_idx(lruvec, LRU_INACTIVE_FILE, sc->reclaim_idx) >> sc->priority) { scan_balance = SCAN_FILE; goto out; } @@ -2295,7 +2324,7 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg, unsigned long size; unsigned long scan; - size = lruvec_lru_size(lruvec, lru); + size = lruvec_lru_size_zone_idx(lruvec, lru, sc->reclaim_idx); scan = size >> sc->priority; if (!scan && pass && force_scan)