Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1358537
| From | Johannes Weiner <hannes@cmpxchg.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage |
| Date | 2016-03-16 06:50 +0100 |
| Message-ID | <rdcvf-4sX-3@gated-at.bofh.it> (permalink) |
| References | <rbfQC-3PQ-5@gated-at.bofh.it> <rbqM1-3qq-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Mar 11, 2016 at 11:34:40AM +0300, Vladimir Davydov wrote: > On Thu, Mar 10, 2016 at 03:50:13PM -0500, Johannes Weiner wrote: > > When setting memory.high below usage, nothing happens until the next > > charge comes along, and then it will only reclaim its own charge and > > not the now potentially huge excess of the new memory.high. This can > > cause groups to stay in excess of their memory.high indefinitely. > > > > To fix that, when shrinking memory.high, kick off a reclaim cycle that > > goes after the delta. > > I agree that we should reclaim the high excess, but I don't think it's a > good idea to do it synchronously. Currently, memory.low and memory.high > knobs can be easily used by a single-threaded load manager implemented > in userspace, because it doesn't need to care about potential stalls > caused by writes to these files. After this change it might happen that > a write to memory.high would take long, seconds perhaps, so in order to > react quickly to changes in other cgroups, a load manager would have to > spawn a thread per each write to memory.high, which would complicate its > implementation significantly. While I do expect memory.high to be adjusted every once in a while, I can't see anybody doing it by a significant fraction of the cgroup every couple of seconds - or tighter than the workingset; and dropping use-once cache is cheap. What kind of usecase would that be? But even if we're wrong about it and this becomes a scalability issue, the knob - even when reclaiming synchroneously - makes no guarantees about the target being met once the write finishes. It's a best effort mechanism. What would break if we made it async later on?
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage Johannes Weiner <hannes@cmpxchg.org> - 2016-03-10 22:00 +0100
Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage Michal Hocko <mhocko@kernel.org> - 2016-03-11 09:00 +0100
Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage Vladimir Davydov <vdavydov@virtuozzo.com> - 2016-03-11 09:40 +0100
Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage Michal Hocko <mhocko@kernel.org> - 2016-03-11 09:50 +0100
Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage Vladimir Davydov <vdavydov@virtuozzo.com> - 2016-03-11 10:20 +0100
Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage Michal Hocko <mhocko@kernel.org> - 2016-03-11 11:00 +0100
Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage Vladimir Davydov <vdavydov@virtuozzo.com> - 2016-03-11 13:00 +0100
Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage Michal Hocko <mhocko@kernel.org> - 2016-03-11 14:50 +0100
Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage Vladimir Davydov <vdavydov@virtuozzo.com> - 2016-03-11 15:10 +0100
Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage Michal Hocko <mhocko@kernel.org> - 2016-03-11 15:30 +0100
Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage Vladimir Davydov <vdavydov@virtuozzo.com> - 2016-03-11 15:50 +0100
Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage Johannes Weiner <hannes@cmpxchg.org> - 2016-03-16 06:50 +0100
Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage Vladimir Davydov <vdavydov@virtuozzo.com> - 2016-03-16 16:30 +0100
csiph-web