On Fri, Mar 22, 2019 at 04:03:07PM +, Chris Down wrote:
> This patch is an incremental improvement on the existing
> memory.{low,min} relative reclaim work to base its scan pressure
> calculations on how much protection is available compared to the current
> usage, rather than how much the curr
Michal Hocko writes:
On Thu 30-05-19 13:52:10, Chris Down wrote:
Michal Hocko writes:
> On Wed 29-05-19 23:44:53, Chris Down wrote:
> > Michal Hocko writes:
> > > Maybe I am missing something so correct me if I am wrong but the new
> > > calculation actually means that we always allow to scan ev
On Thu 30-05-19 13:52:10, Chris Down wrote:
> Michal Hocko writes:
> > On Wed 29-05-19 23:44:53, Chris Down wrote:
> > > Michal Hocko writes:
> > > > Maybe I am missing something so correct me if I am wrong but the new
> > > > calculation actually means that we always allow to scan even min
> > > >
Michal Hocko writes:
On Wed 29-05-19 23:44:53, Chris Down wrote:
Michal Hocko writes:
> Maybe I am missing something so correct me if I am wrong but the new
> calculation actually means that we always allow to scan even min
> protected memcgs right?
We check if the memcg is min protected as a p
On Wed 29-05-19 23:44:53, Chris Down wrote:
> Michal Hocko writes:
> > Maybe I am missing something so correct me if I am wrong but the new
> > calculation actually means that we always allow to scan even min
> > protected memcgs right?
>
> We check if the memcg is min protected as a precondition
Michal Hocko writes:
Maybe I am missing something so correct me if I am wrong but the new
calculation actually means that we always allow to scan even min
protected memcgs right?
We check if the memcg is min protected as a precondition for coming into this
function at all, so this generally is
[Sorry for a late reply]
On Fri 22-03-19 16:03:07, Chris Down wrote:
[...]
> With this patch, memory.low and memory.min affect reclaim pressure in a
> more understandable and composable way. For example, from a user
> standpoint, "protected" memory now remains untouchable from a reclaim
> aggressi
Chris Down writes:
Are you certain? If so, I don't see what you mean. This is how the
code looks in Linus' tree after the fixups:
Hmm, apparently this actually didn't go into Linus' tree yet, so yeah, seems
worth having as a fixup maybe indeed.
On Fri, Mar 22, 2019 at 10:49:46PM +, Chris Down wrote:
> Roman Gushchin writes:
> > I've noticed that the old version is just wrong: if cgroup_size is way
> > smaller
> > than max(min, low), scan will be set to -lruvec_size.
> > Given that it's unsigned long, we'll end up with scanning the wh
Roman Gushchin writes:
However, we can race with the emin/elow update and end up with negative scan,
especially if cgroup_size is about the effective protection size
Yeah, it's possible but unlikely, hence the TOCTOU check. :-)
On Fri, Mar 22, 2019 at 03:29:10PM -0700, Roman Gushchin wrote:
> On Fri, Mar 22, 2019 at 04:03:07PM +, Chris Down wrote:
> > This patch is an incremental improvement on the existing
> > memory.{low,min} relative reclaim work to base its scan pressure
> > calculations on how much protection is
Roman Gushchin writes:
I've noticed that the old version is just wrong: if cgroup_size is way smaller
than max(min, low), scan will be set to -lruvec_size.
Given that it's unsigned long, we'll end up with scanning the whole list
(due to clamp() below).
Are you certain? If so, I don't see what y
On Fri, Mar 22, 2019 at 04:03:07PM +, Chris Down wrote:
> This patch is an incremental improvement on the existing
> memory.{low,min} relative reclaim work to base its scan pressure
> calculations on how much protection is available compared to the current
> usage, rather than how much the curr
Andrew Morton writes:
Could you please provide more description of the effect this has upon
userspace? Preferably in real-world cases. What problems were being
observed and how does this improve things?
Sure! The previous patch's behaviour isn't so much problematic as it is just
not as feat
On Fri, 22 Mar 2019 16:03:07 + Chris Down wrote:
> This patch is an incremental improvement on the existing
> memory.{low,min} relative reclaim work to base its scan pressure
> calculations on how much protection is available compared to the current
> usage, rather than how much the current u
This patch is an incremental improvement on the existing
memory.{low,min} relative reclaim work to base its scan pressure
calculations on how much protection is available compared to the current
usage, rather than how much the current usage is over some protection
threshold.
Previously the way tha
16 matches
Mail list logo
