Re: [PATCH 2/3] memcg: ratify and consolidate over-charge handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello, Michal.

On Tue, Sep 15, 2015 at 10:01:10AM +0200, Michal Hocko wrote:
> > > OK the code is easier in the end, although I would argue that try_charge
> > > could return ENOMEM for GFP_NOWAIT instead of overcharging (this would
> > > e.g. allow precharge to bail out earlier). Something for a separate patch I
> > > guess.
> > 
> > Hmm... GFP_NOWAIT is failed unless it also has __GFP_NOFAIL.
> 
> Yes I wasn't clear, sorry, it fails but TIF_MEMDIE or killed/exiting
> context would still overcharge GFP_NOWAIT requests rather than failing
> them. Something for a separate patch though.

Ah, I see.  I'm not sure that'd matter one way or the other tho.

> > I don't even think this is an implementation detail.
> 
> I really think this is an implementation detail because we can force
> the implementation to never overcharge. Just retry indefinitely for

But we actively choose not to and I think that's an architectural
decision.

> I am not sure I understand here. High and max are basically resembling
> watermarks for the global case. Sure max/high can be set independently
> which is not the case for the global case which calculates them from
> min_free_kbytes but why would that matter and make them different?

Yes, there are similarities but if we really wanted to emulate global
case, we'd just have the hardlimit and then have async reclaim to keep
certain level of reserves and so on.

I don't think it'd be meaningful to try to follow the limit strictly
under all circumstances.  It's not like we can track all memory
consumption to begin with.  There always is common consumption which
can't clearly be distributed to specific cgroups which makes literal
strictness rather pointless.  Also, I'm pretty sure there will always
be enough cases where it is saner to temporarily breach the limit in
small scale just because exhaustion of memory inside a cgroup doesn't
mean global exhaustion and that's an inherent characteristic of what
memcg does.

Anyways, I don't think this difference in viewpoints matters that
much.

Thanks.

-- 
tejun

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]