Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1596085
| From | Rik van Riel <riel@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever |
| Date | 2017-03-09 15:20 +0100 |
| Message-ID | <tj757-6kn-3@gated-at.bofh.it> (permalink) |
| References | <tinOG-8fM-5@gated-at.bofh.it> <titAK-46W-21@gated-at.bofh.it> <tiGxY-4My-27@gated-at.bofh.it> <tiMk2-uK-11@gated-at.bofh.it> <tj2yu-3cS-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
On Thu, 2017-03-09 at 10:12 +0100, Michal Hocko wrote:
> On Wed 08-03-17 10:54:57, Rik van Riel wrote:
> > In fact, false OOM kills with that kind of workload is
> > how we ended up getting the "too many isolated" logic
> > in the first place.
> Right, but the retry logic was considerably different than what we
> have these days. should_reclaim_retry considers amount of reclaimable
> memory. As I've said earlier if we see a report where the oom hits
> prematurely with many NR_ISOLATED* we know how to fix that.
Would it be enough to simply reset no_progress_loops
in this check inside should_reclaim_retry, if we know
pageout IO is pending?
if (!did_some_progress) {
unsigned long write_pending;
write_pending =
zone_page_state_snapshot(zone,
NR_ZONE_WRITE_P
ENDING);
if (2 * write_pending > reclaimable) {
congestion_wait(BLK_RW_ASYNC,
HZ/10);
return true;
}
}
--
All rights reversed
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] mm, vmscan: do not loop on too_many_isolated for ever Michal Hocko <mhocko@kernel.org> - 2017-03-07 15:00 +0100
Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever Rik van Riel <riel@redhat.com> - 2017-03-07 21:10 +0100
Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever Michal Hocko <mhocko@kernel.org> - 2017-03-08 11:00 +0100
Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever Rik van Riel <riel@redhat.com> - 2017-03-08 17:10 +0100
Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever Michal Hocko <mhocko@kernel.org> - 2017-03-09 10:30 +0100
Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever Rik van Riel <riel@redhat.com> - 2017-03-09 15:20 +0100
Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever Michal Hocko <mhocko@kernel.org> - 2017-03-09 16:00 +0100
Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever Johannes Weiner <hannes@cmpxchg.org> - 2017-03-09 19:20 +0100
Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever Rik van Riel <riel@redhat.com> - 2017-03-09 23:20 +0100
Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever Michal Hocko <mhocko@kernel.org> - 2017-03-10 11:30 +0100
Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever Michal Hocko <mhocko@kernel.org> - 2017-03-10 11:30 +0100
Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-03-10 12:50 +0100
Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever Mel Gorman <mgorman@suse.de> - 2017-03-09 15:40 +0100
csiph-web