Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1392250 > unrolled thread
| Started by | Vlastimil Babka <vbabka@suse.cz> |
|---|---|
| First post | 2016-05-02 16:50 +0200 |
| Last post | 2016-05-03 12:10 +0200 |
| Articles | 7 — 4 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: mm: pages are not freed from lru_add_pvecs after process termination Vlastimil Babka <vbabka@suse.cz> - 2016-05-02 16:50 +0200
Re: mm: pages are not freed from lru_add_pvecs after process termination "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-05-02 17:10 +0200
Re: mm: pages are not freed from lru_add_pvecs after process termination Vlastimil Babka <vbabka@suse.cz> - 2016-05-02 17:20 +0200
Re: mm: pages are not freed from lru_add_pvecs after process termination Dave Hansen <dave.hansen@intel.com> - 2016-05-02 17:50 +0200
Re: mm: pages are not freed from lru_add_pvecs after process termination "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-05-02 18:10 +0200
Re: mm: pages are not freed from lru_add_pvecs after process termination Michal Hocko <mhocko@kernel.org> - 2016-05-03 09:40 +0200
Re: mm: pages are not freed from lru_add_pvecs after process termination "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-05-03 12:10 +0200
| From | Vlastimil Babka <vbabka@suse.cz> |
|---|---|
| Date | 2016-05-02 16:50 +0200 |
| Subject | Re: mm: pages are not freed from lru_add_pvecs after process termination |
| Message-ID | <runkD-58W-33@gated-at.bofh.it> |
On 04/27/2016 07:11 PM, Dave Hansen wrote: > 6. Perhaps don't use the LRU pagevecs for large pages. It limits the > severity of the problem. I think that makes sense. Being large already amortizes the cost per base page much more than pagevecs do (512 vs ~22 pages?).
[toc] | [next] | [standalone]
| From | "Kirill A. Shutemov" <kirill@shutemov.name> |
|---|---|
| Date | 2016-05-02 17:10 +0200 |
| Message-ID | <runDY-5IL-11@gated-at.bofh.it> |
| In reply to | #1392250 |
On Mon, May 02, 2016 at 04:39:35PM +0200, Vlastimil Babka wrote: > On 04/27/2016 07:11 PM, Dave Hansen wrote: > >6. Perhaps don't use the LRU pagevecs for large pages. It limits the > > severity of the problem. > > I think that makes sense. Being large already amortizes the cost per base > page much more than pagevecs do (512 vs ~22 pages?). We try to do this already, don't we? Any spefic case where we have THPs on pagevecs? -- Kirill A. Shutemov
[toc] | [prev] | [next] | [standalone]
| From | Vlastimil Babka <vbabka@suse.cz> |
|---|---|
| Date | 2016-05-02 17:20 +0200 |
| Message-ID | <runNE-5Nz-7@gated-at.bofh.it> |
| In reply to | #1392270 |
On 05/02/2016 05:01 PM, Kirill A. Shutemov wrote:
> On Mon, May 02, 2016 at 04:39:35PM +0200, Vlastimil Babka wrote:
>> On 04/27/2016 07:11 PM, Dave Hansen wrote:
>>> 6. Perhaps don't use the LRU pagevecs for large pages. It limits the
>>> severity of the problem.
>>
>> I think that makes sense. Being large already amortizes the cost per base
>> page much more than pagevecs do (512 vs ~22 pages?).
>
> We try to do this already, don't we? Any spefic case where we have THPs on
> pagevecs?
For example like this?
__do_huge_pmd_anonymous_page
lru_cache_add_active_or_unevictable
lru_cache_add
[toc] | [prev] | [next] | [standalone]
| From | Dave Hansen <dave.hansen@intel.com> |
|---|---|
| Date | 2016-05-02 17:50 +0200 |
| Message-ID | <ruogF-66V-1@gated-at.bofh.it> |
| In reply to | #1392270 |
On 05/02/2016 08:01 AM, Kirill A. Shutemov wrote: > On Mon, May 02, 2016 at 04:39:35PM +0200, Vlastimil Babka wrote: >> On 04/27/2016 07:11 PM, Dave Hansen wrote: >>> 6. Perhaps don't use the LRU pagevecs for large pages. It limits the >>> severity of the problem. >> >> I think that makes sense. Being large already amortizes the cost per base >> page much more than pagevecs do (512 vs ~22 pages?). > > We try to do this already, don't we? Any spefic case where we have THPs on > pagevecs? Lukas was hitting this on a RHEL 7 era kernel. In his kernel at least, I'm pretty sure THP's were ending up on pagevecs. Are you saying you don't think we're doing that any more?
[toc] | [prev] | [next] | [standalone]
| From | "Kirill A. Shutemov" <kirill@shutemov.name> |
|---|---|
| Date | 2016-05-02 18:10 +0200 |
| Message-ID | <ruoA2-6AD-19@gated-at.bofh.it> |
| In reply to | #1392316 |
On Mon, May 02, 2016 at 08:49:03AM -0700, Dave Hansen wrote: > On 05/02/2016 08:01 AM, Kirill A. Shutemov wrote: > > On Mon, May 02, 2016 at 04:39:35PM +0200, Vlastimil Babka wrote: > >> On 04/27/2016 07:11 PM, Dave Hansen wrote: > >>> 6. Perhaps don't use the LRU pagevecs for large pages. It limits the > >>> severity of the problem. > >> > >> I think that makes sense. Being large already amortizes the cost per base > >> page much more than pagevecs do (512 vs ~22 pages?). > > > > We try to do this already, don't we? Any spefic case where we have THPs on > > pagevecs? > > Lukas was hitting this on a RHEL 7 era kernel. In his kernel at least, > I'm pretty sure THP's were ending up on pagevecs. Are you saying you > don't think we're doing that any more? As Vlastimil pointed, we do. It need to be fixed, I think. Any volunteer? :-P -- Kirill A. Shutemov
[toc] | [prev] | [next] | [standalone]
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Date | 2016-05-03 09:40 +0200 |
| Message-ID | <ruD62-3HL-21@gated-at.bofh.it> |
| In reply to | #1392338 |
On Mon 02-05-16 19:02:50, Kirill A. Shutemov wrote: > On Mon, May 02, 2016 at 08:49:03AM -0700, Dave Hansen wrote: > > On 05/02/2016 08:01 AM, Kirill A. Shutemov wrote: > > > On Mon, May 02, 2016 at 04:39:35PM +0200, Vlastimil Babka wrote: > > >> On 04/27/2016 07:11 PM, Dave Hansen wrote: > > >>> 6. Perhaps don't use the LRU pagevecs for large pages. It limits the > > >>> severity of the problem. > > >> > > >> I think that makes sense. Being large already amortizes the cost per base > > >> page much more than pagevecs do (512 vs ~22 pages?). > > > > > > We try to do this already, don't we? Any spefic case where we have THPs on > > > pagevecs? > > > > Lukas was hitting this on a RHEL 7 era kernel. In his kernel at least, > > I'm pretty sure THP's were ending up on pagevecs. Are you saying you > > don't think we're doing that any more? > > As Vlastimil pointed, we do. It need to be fixed, I think. It seems that offloading the draining to the vmstat context doesn't look terribly bad. Don't we rather want to go that way? -- Michal Hocko SUSE Labs
[toc] | [prev] | [next] | [standalone]
| From | "Kirill A. Shutemov" <kirill@shutemov.name> |
|---|---|
| Date | 2016-05-03 12:10 +0200 |
| Message-ID | <ruFrc-6jc-19@gated-at.bofh.it> |
| In reply to | #1393115 |
On Tue, May 03, 2016 at 09:37:57AM +0200, Michal Hocko wrote: > On Mon 02-05-16 19:02:50, Kirill A. Shutemov wrote: > > On Mon, May 02, 2016 at 08:49:03AM -0700, Dave Hansen wrote: > > > On 05/02/2016 08:01 AM, Kirill A. Shutemov wrote: > > > > On Mon, May 02, 2016 at 04:39:35PM +0200, Vlastimil Babka wrote: > > > >> On 04/27/2016 07:11 PM, Dave Hansen wrote: > > > >>> 6. Perhaps don't use the LRU pagevecs for large pages. It limits the > > > >>> severity of the problem. > > > >> > > > >> I think that makes sense. Being large already amortizes the cost per base > > > >> page much more than pagevecs do (512 vs ~22 pages?). > > > > > > > > We try to do this already, don't we? Any spefic case where we have THPs on > > > > pagevecs? > > > > > > Lukas was hitting this on a RHEL 7 era kernel. In his kernel at least, > > > I'm pretty sure THP's were ending up on pagevecs. Are you saying you > > > don't think we're doing that any more? > > > > As Vlastimil pointed, we do. It need to be fixed, I think. > > It seems that offloading the draining to the vmstat context doesn't look > terribly bad. Don't we rather want to go that way? Maybe. My knowledge about lru cache is limited. -- Kirill A. Shutemov
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web