[LSF/MM ATTEND] Attend mm summit 2018

[LSF/MM ATTEND] Attend mm summit 2018

[Balbir Singh]

I did not send out an official request to attend earlier, but I was
invited by Jerome to attend. I was traveling for a big part of Jan and
some part of Feb 2018 and hence the delay in sending out this email
with my desire to attend

I did a proposal last year for N_COHERENT_MEMORY, but there was
suggestions that for coherent memory we do ZONE_DEVICE and thus
HMM/CDM came into the picture. I have good knowledge of the memory
cgroups subsystem and have been looking at HMM and HMM/CDM for over a
year now and playing with ZONE_DEVICE in general. I would like to
attend to learn and discuss on the following topics

1. HMM and HMM-CDM and arguments for whether NUMA makes sense or not.
Experiences gained with both technologies.
2. Memory cgroups - I don't see a pressing need for many new features,
but I'd like to see if we can revive some old proposals around virtual
memory limits

Balbir Singh.

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

Re: [LSF/MM ATTEND] Attend mm summit 2018

[Michal Hocko]

On Thu 22-02-18 13:54:46, Balbir Singh wrote:
[...]
> 2. Memory cgroups - I don't see a pressing need for many new features,
> but I'd like to see if we can revive some old proposals around virtual
> memory limits

Could you be more specific about usecase(s)?
-- 
Michal Hocko
SUSE Labs

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

Re: [LSF/MM ATTEND] Attend mm summit 2018

[Balbir Singh]

On Fri, Feb 23, 2018 at 12:03 AM, Michal Hocko <mhocko@kernel.org> wrote:
> On Thu 22-02-18 13:54:46, Balbir Singh wrote:
> [...]
>> 2. Memory cgroups - I don't see a pressing need for many new features,
>> but I'd like to see if we can revive some old proposals around virtual
>> memory limits
>
> Could you be more specific about usecase(s)?

I had for a long time a virtual memory limit controller in -mm tree.
The use case was to fail allocations as opposed to OOM'ing in the
worst case as we do with the cgroup memory limits (actual page usage
control). I did not push for it then since I got side-tracked. I'd
like to pursue a use case for being able to fail allocations as
opposed to OOM'ing on a per cgroup basis. I'd like to start the
discussion again.

Balbir Singh.

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

Re: [Lsf-pc] [LSF/MM ATTEND] Attend mm summit 2018

[Michal Hocko]

On Fri 23-02-18 00:23:53, Balbir Singh wrote:
> On Fri, Feb 23, 2018 at 12:03 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > On Thu 22-02-18 13:54:46, Balbir Singh wrote:
> > [...]
> >> 2. Memory cgroups - I don't see a pressing need for many new features,
> >> but I'd like to see if we can revive some old proposals around virtual
> >> memory limits
> >
> > Could you be more specific about usecase(s)?
> 
> I had for a long time a virtual memory limit controller in -mm tree.
> The use case was to fail allocations as opposed to OOM'ing in the
> worst case as we do with the cgroup memory limits (actual page usage
> control). I did not push for it then since I got side-tracked. I'd
> like to pursue a use case for being able to fail allocations as
> opposed to OOM'ing on a per cgroup basis. I'd like to start the
> discussion again.

So you basically want the strict no overcommit on the per memcg level?
I am really skeptical, to be completely honest. The global behavior is
not very usable in most cases already. Making it per-memcg will just
amplify all the issues (application tend to overcommit their virtual
address space). Not to mention that you cannot really prevent from the
OOM killer because there are allocations outside of the address space.

So if you want to push this forward you really need a very good existing
usecase to justifiy the change.
-- 
Michal Hocko
SUSE Labs

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

virtual memory limits control (was Re: [Lsf-pc] [LSF/MM ATTEND] Attend mm summit 2018)

[Balbir Singh]

Changed the subject to reflect the discussion

On Thu, 22 Feb 2018 14:34:25 +0100
Michal Hocko <mhocko@kernel.org> wrote:

> On Fri 23-02-18 00:23:53, Balbir Singh wrote:
> > On Fri, Feb 23, 2018 at 12:03 AM, Michal Hocko <mhocko@kernel.org> wrote:  
> > > On Thu 22-02-18 13:54:46, Balbir Singh wrote:
> > > [...]  
> > >> 2. Memory cgroups - I don't see a pressing need for many new features,
> > >> but I'd like to see if we can revive some old proposals around virtual
> > >> memory limits  
> > >
> > > Could you be more specific about usecase(s)?  
> > 
> > I had for a long time a virtual memory limit controller in -mm tree.
> > The use case was to fail allocations as opposed to OOM'ing in the
> > worst case as we do with the cgroup memory limits (actual page usage
> > control). I did not push for it then since I got side-tracked. I'd
> > like to pursue a use case for being able to fail allocations as
> > opposed to OOM'ing on a per cgroup basis. I'd like to start the
> > discussion again.  
> 
> So you basically want the strict no overcommit on the per memcg level?

I don't think it implies strict no overcommit, the value sets the
overcommit ratio (independent of the global vm.overcommit_ratio, which
we can discuss on the side, since I don't want it to impact the use
case).

The goal of the controller was  (and its optional, may not work well
for sparse address spaces)

1. set the vm limit
2. If the limit is exceeded, fail at malloc()/mmap() as opposed to
OOM'ing at page fault time
3. Application handles the fault and decide not to proceed with the
new task that needed more memory

I think this leads to applications being able to deal with failures
better. OOM is a big hammer

> I am really skeptical, to be completely honest. The global behavior is
> not very usable in most cases already. Making it per-memcg will just
> amplify all the issues (application tend to overcommit their virtual
> address space). Not to mention that you cannot really prevent from the
> OOM killer because there are allocations outside of the address space.
> 

Could you clarify on the outside address space -- as in shared
allocations outside the cgroup?  kernel allocations as a side-effect?

> So if you want to push this forward you really need a very good existing
> usecase to justifiy the change.

I want to start the discussion again.

Balbir Singh.

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

Re: virtual memory limits control (was Re: [Lsf-pc] [LSF/MM ATTEND] Attend mm summit 2018)

[Michal Hocko]

On Fri 23-02-18 09:01:23, Balbir Singh wrote:
> Changed the subject to reflect the discussion
> 
> On Thu, 22 Feb 2018 14:34:25 +0100
> Michal Hocko <mhocko@kernel.org> wrote:
> 
> > On Fri 23-02-18 00:23:53, Balbir Singh wrote:
> > > On Fri, Feb 23, 2018 at 12:03 AM, Michal Hocko <mhocko@kernel.org> wrote:  
> > > > On Thu 22-02-18 13:54:46, Balbir Singh wrote:
> > > > [...]  
> > > >> 2. Memory cgroups - I don't see a pressing need for many new features,
> > > >> but I'd like to see if we can revive some old proposals around virtual
> > > >> memory limits  
> > > >
> > > > Could you be more specific about usecase(s)?  
> > > 
> > > I had for a long time a virtual memory limit controller in -mm tree.
> > > The use case was to fail allocations as opposed to OOM'ing in the
> > > worst case as we do with the cgroup memory limits (actual page usage
> > > control). I did not push for it then since I got side-tracked. I'd
> > > like to pursue a use case for being able to fail allocations as
> > > opposed to OOM'ing on a per cgroup basis. I'd like to start the
> > > discussion again.  
> > 
> > So you basically want the strict no overcommit on the per memcg level?
> 
> I don't think it implies strict no overcommit, the value sets the
> overcommit ratio (independent of the global vm.overcommit_ratio, which
> we can discuss on the side, since I don't want it to impact the use
> case).
> 
> The goal of the controller was  (and its optional, may not work well
> for sparse address spaces)
> 
> 1. set the vm limit
> 2. If the limit is exceeded, fail at malloc()/mmap() as opposed to
> OOM'ing at page fault time

this is basically strict no-overcommit

> 3. Application handles the fault and decide not to proceed with the
> new task that needed more memory

So you do not return ENOMEM but rather raise a signal? What that would
be?

> I think this leads to applications being able to deal with failures
> better. OOM is a big hammer

Do you have any _specific_ usecase in mind?
 
> > I am really skeptical, to be completely honest. The global behavior is
> > not very usable in most cases already. Making it per-memcg will just
> > amplify all the issues (application tend to overcommit their virtual
> > address space). Not to mention that you cannot really prevent from the
> > OOM killer because there are allocations outside of the address space.
> > 
> 
> Could you clarify on the outside address space -- as in shared
> allocations outside the cgroup?  kernel allocations as a side-effect?

basically anything that can be triggered from userspace and doesn't map
into the address space - page cache, fs metadata, drm buffers etc...
-- 
Michal Hocko
SUSE Labs

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

Re: virtual memory limits control (was Re: [Lsf-pc] [LSF/MM ATTEND] Attend mm summit 2018)

[Balbir Singh]

-lsf-pc (I can add them back, but I did not want to spam the group)
+Vladimir

On Fri, 23 Feb 2018 08:42:01 +0100
Michal Hocko <mhocko@kernel.org> wrote:

> On Fri 23-02-18 09:01:23, Balbir Singh wrote:
> > Changed the subject to reflect the discussion
> > 
> > On Thu, 22 Feb 2018 14:34:25 +0100
> > Michal Hocko <mhocko@kernel.org> wrote:
> >   
> > > On Fri 23-02-18 00:23:53, Balbir Singh wrote:  
> > > > On Fri, Feb 23, 2018 at 12:03 AM, Michal Hocko <mhocko@kernel.org> wrote:    
> > > > > On Thu 22-02-18 13:54:46, Balbir Singh wrote:
> > > > > [...]    
> > > > >> 2. Memory cgroups - I don't see a pressing need for many new features,
> > > > >> but I'd like to see if we can revive some old proposals around virtual
> > > > >> memory limits    
> > > > >
> > > > > Could you be more specific about usecase(s)?    
> > > > 
> > > > I had for a long time a virtual memory limit controller in -mm tree.
> > > > The use case was to fail allocations as opposed to OOM'ing in the
> > > > worst case as we do with the cgroup memory limits (actual page usage
> > > > control). I did not push for it then since I got side-tracked. I'd
> > > > like to pursue a use case for being able to fail allocations as
> > > > opposed to OOM'ing on a per cgroup basis. I'd like to start the
> > > > discussion again.    
> > > 
> > > So you basically want the strict no overcommit on the per memcg level?  
> > 
> > I don't think it implies strict no overcommit, the value sets the
> > overcommit ratio (independent of the global vm.overcommit_ratio, which
> > we can discuss on the side, since I don't want it to impact the use
> > case).
> > 
> > The goal of the controller was  (and its optional, may not work well
> > for sparse address spaces)
> > 
> > 1. set the vm limit
> > 2. If the limit is exceeded, fail at malloc()/mmap() as opposed to
> > OOM'ing at page fault time  
> 
> this is basically strict no-overcommit

I look at it more as Committed_AS accounting and controls not controlled
or driven by CommitLimit, but something the administrator can derive,
but your right the defaults would be CommitLimit

> 
> > 3. Application handles the fault and decide not to proceed with the
> > new task that needed more memory  
> 
> So you do not return ENOMEM but rather raise a signal? What that would
> be?

Nope, it will return ENOMEM

> 
> > I think this leads to applications being able to deal with failures
> > better. OOM is a big hammer  
> 
> Do you have any _specific_ usecase in mind?

It's mostly my frustration with OOM kills I see, granted a lot of it is
about sizing the memory cgroup correctly, but that is not an easy job.

>  
> > > I am really skeptical, to be completely honest. The global behavior is
> > > not very usable in most cases already. Making it per-memcg will just
> > > amplify all the issues (application tend to overcommit their virtual
> > > address space). Not to mention that you cannot really prevent from the
> > > OOM killer because there are allocations outside of the address space.
> > >   
> > 
> > Could you clarify on the outside address space -- as in shared
> > allocations outside the cgroup?  kernel allocations as a side-effect?  
> 
> basically anything that can be triggered from userspace and doesn't map
> into the address space - page cache, fs metadata, drm buffers etc...

Yep, the virtual memory limits controller is more about the Committed_AS.

I also noticed that Vladimir tried something similar at
https://lkml.org/lkml/2014/7/3/405

Balbir Singh.

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