[LSF/MM TOPIC] slab reclaim

[LSF/MM TOPIC] slab reclaim

[Michal Hocko]

Hi,
I would like to propose the following for LSF/MM discussion. Both MM and
FS people should be involved.

The current way of the slab reclaim is rather suboptimal from 2
perspectives.

1) The slab allocator relies on shrinkers to release pages but shrinkers
are object rather than page based. This means that the memory reclaim
asks to free some pages, slab asks shrinkers to free some objects
and the result might be that nothing really gets freed even though
shrinkers do their jobs properly because some objects are still pinning
the page. This is not a new problem and it has been discussed in the
past. Dave Chinner has even suggested a solution [1] which sounds like
the right approach. There was no follow up and I believe we should
into implementing it.

2) The way we scale slab reclaim pressure depends on the regular LRU
reclaim. There are workloads which do not general a lot of pages on LRUs
while they still consume a lot of slab memory. We can end up even going
OOM because the slab reclaim doesn't free up enough. I am not really
sure how the proper solution should look like but either we need some
way of slab consumption throttling or we need a more clever slab
pressure estimation.

[1] https://lkml.org/lkml/2010/2/8/329.
-- 
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-pc] [LSF/MM TOPIC] slab reclaim

[Jan Kara]

Hi!

On Wed 28-12-16 14:09:51, Michal Hocko wrote:
> I would like to propose the following for LSF/MM discussion. Both MM and
> FS people should be involved.
> 
> The current way of the slab reclaim is rather suboptimal from 2
> perspectives.
> 
> 1) The slab allocator relies on shrinkers to release pages but shrinkers
> are object rather than page based. This means that the memory reclaim
> asks to free some pages, slab asks shrinkers to free some objects
> and the result might be that nothing really gets freed even though
> shrinkers do their jobs properly because some objects are still pinning
> the page. This is not a new problem and it has been discussed in the
> past. Dave Chinner has even suggested a solution [1] which sounds like
> the right approach. There was no follow up and I believe we should
> into implementing it.
> 
> 2) The way we scale slab reclaim pressure depends on the regular LRU
> reclaim. There are workloads which do not general a lot of pages on LRUs
> while they still consume a lot of slab memory. We can end up even going
> OOM because the slab reclaim doesn't free up enough. I am not really
> sure how the proper solution should look like but either we need some
> way of slab consumption throttling or we need a more clever slab
> pressure estimation.
> 
> [1] https://lkml.org/lkml/2010/2/8/329.

I'm interested in this topic although I think it currently needs more
coding and experimenting than discussions...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

--
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 TOPIC] slab reclaim

[Vlastimil Babka]

On 01/02/2017 12:02 PM, Jan Kara wrote:
> Hi!
> 
> On Wed 28-12-16 14:09:51, Michal Hocko wrote:
>> I would like to propose the following for LSF/MM discussion. Both MM and
>> FS people should be involved.
>>
>> The current way of the slab reclaim is rather suboptimal from 2
>> perspectives.
>>
>> 1) The slab allocator relies on shrinkers to release pages but shrinkers
>> are object rather than page based. This means that the memory reclaim
>> asks to free some pages, slab asks shrinkers to free some objects
>> and the result might be that nothing really gets freed even though
>> shrinkers do their jobs properly because some objects are still pinning
>> the page. This is not a new problem and it has been discussed in the
>> past. Dave Chinner has even suggested a solution [1] which sounds like
>> the right approach. There was no follow up and I believe we should
>> into implementing it.
>>
>> 2) The way we scale slab reclaim pressure depends on the regular LRU
>> reclaim. There are workloads which do not general a lot of pages on LRUs
>> while they still consume a lot of slab memory. We can end up even going
>> OOM because the slab reclaim doesn't free up enough. I am not really
>> sure how the proper solution should look like but either we need some
>> way of slab consumption throttling or we need a more clever slab
>> pressure estimation.
>>
>> [1] https://lkml.org/lkml/2010/2/8/329.
> 
> I'm interested in this topic although I think it currently needs more
> coding and experimenting than discussions...

Yeah, some of the related stuff that was discussed at Kernel Summit [1]
would be nice to have at least prototyped, i.e. the dentry cache
separation and the slab helper for providing objects on the same page?

[1] https://lwn.net/Articles/705758/

> 
> 								Honza
> 

--
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 TOPIC] slab reclaim

[Christoph Lameter]

On Thu, 5 Jan 2017, Vlastimil Babka wrote:

>
> Yeah, some of the related stuff that was discussed at Kernel Summit [1]
> would be nice to have at least prototyped, i.e. the dentry cache
> separation and the slab helper for providing objects on the same page?
>
> [1] https://lwn.net/Articles/705758/

Hmmm. Sorry I am a bit late reading this I think. But I have a patchset
that addresses some of these issues. See https://lwn.net/Articles/371892/
Would like to rework some of that for the current kernel sources. Matthew
Wilcox told me that he may be able top use this to implement
reclaim/defrag in the radix tree code.

--
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 TOPIC] slab reclaim

[Michal Hocko]

On Mon 30-01-17 12:47:04, Cristopher Lameter wrote:
> On Thu, 5 Jan 2017, Vlastimil Babka wrote:
> 
> >
> > Yeah, some of the related stuff that was discussed at Kernel Summit [1]
> > would be nice to have at least prototyped, i.e. the dentry cache
> > separation and the slab helper for providing objects on the same page?
> >
> > [1] https://lwn.net/Articles/705758/
> 
> Hmmm. Sorry I am a bit late reading this I think. But I have a patchset
> that addresses some of these issues. See https://lwn.net/Articles/371892/

Yeah, this is the email thread I have referenced in my initial email. I
didn't reference the first email because Dave had some concerns about
your approach and then the discussion moved on to an approach which
sounds reasonable to me [2]

[2] https://lkml.org/lkml/2010/2/8/329

-- 
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-pc] [LSF/MM TOPIC] slab reclaim

[Christoph Lameter]

On Fri, 10 Feb 2017, Michal Hocko wrote:

> Yeah, this is the email thread I have referenced in my initial email. I
> didn't reference the first email because Dave had some concerns about
> your approach and then the discussion moved on to an approach which
> sounds reasonable to me [2]
>
> [2] https://lkml.org/lkml/2010/2/8/329

Dont see much there to go on aside from the statement of the problem.

--
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>