Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1235908 > unrolled thread
| Started by | Vitaly Wool <vitalywool@gmail.com> |
|---|---|
| First post | 2015-09-30 11:00 +0200 |
| Last post | 2015-09-30 17:20 +0200 |
| Articles | 5 — 3 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: [PATCH 12/12] mm, page_alloc: Only enforce watermarks for order-0 allocations Vitaly Wool <vitalywool@gmail.com> - 2015-09-30 11:00 +0200
Re: [PATCH 12/12] mm, page_alloc: Only enforce watermarks for order-0 allocations Vlastimil Babka <vbabka@suse.cz> - 2015-09-30 16:00 +0200
Re: [PATCH 12/12] mm, page_alloc: Only enforce watermarks for order-0 allocations Vitaly Wool <vitalywool@gmail.com> - 2015-09-30 16:20 +0200
Re: [PATCH 12/12] mm, page_alloc: Only enforce watermarks for order-0 allocations Vlastimil Babka <vbabka@suse.cz> - 2015-09-30 16:50 +0200
Re: [PATCH 12/12] mm, page_alloc: Only enforce watermarks for order-0 allocations Mel Gorman <mgorman@techsingularity.net> - 2015-09-30 17:20 +0200
| From | Vitaly Wool <vitalywool@gmail.com> |
|---|---|
| Date | 2015-09-30 11:00 +0200 |
| Subject | Re: [PATCH 12/12] mm, page_alloc: Only enforce watermarks for order-0 allocations |
| Message-ID | <qelp0-8sJ-7@gated-at.bofh.it> |
On Wed, Sep 9, 2015 at 2:39 PM, Mel Gorman <mgorman@techsingularity.net> wrote: > On Tue, Sep 08, 2015 at 05:26:13PM +0900, Joonsoo Kim wrote: >> 2015-08-24 21:30 GMT+09:00 Mel Gorman <mgorman@techsingularity.net>: >> > The primary purpose of watermarks is to ensure that reclaim can always >> > make forward progress in PF_MEMALLOC context (kswapd and direct reclaim). >> > These assume that order-0 allocations are all that is necessary for >> > forward progress. >> > >> > High-order watermarks serve a different purpose. Kswapd had no high-order >> > awareness before they were introduced (https://lkml.org/lkml/2004/9/5/9). >> > This was particularly important when there were high-order atomic requests. >> > The watermarks both gave kswapd awareness and made a reserve for those >> > atomic requests. >> > >> > There are two important side-effects of this. The most important is that >> > a non-atomic high-order request can fail even though free pages are available >> > and the order-0 watermarks are ok. The second is that high-order watermark >> > checks are expensive as the free list counts up to the requested order must >> > be examined. >> > >> > With the introduction of MIGRATE_HIGHATOMIC it is no longer necessary to >> > have high-order watermarks. Kswapd and compaction still need high-order >> > awareness which is handled by checking that at least one suitable high-order >> > page is free. >> >> I still don't think that this one suitable high-order page is enough. >> If fragmentation happens, there would be no order-2 freepage. If kswapd >> prepares only 1 order-2 freepage, one of two successive process forks >> (AFAIK, fork in x86 and ARM require order 2 page) must go to direct reclaim >> to make order-2 freepage. Kswapd cannot make order-2 freepage in that >> short time. It causes latency to many high-order freepage requestor >> in fragmented situation. >> > > So what do you suggest instead? A fixed number, some other heuristic? > You have pushed several times now for the series to focus on the latency > of standard high-order allocations but again I will say that it is outside > the scope of this series. If you want to take steps to reduce the latency > of ordinary high-order allocation requests that can sleep then it should > be a separate series. I do believe https://lkml.org/lkml/2015/9/9/313 does a better job here. I have to admit the patch header is a bit misleading here since we don't actually exclude CMA pages, we just _fix_ the calculation in the loop which is utterly wrong otherwise. ~vitaly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Vlastimil Babka <vbabka@suse.cz> |
|---|---|
| Date | 2015-09-30 16:00 +0200 |
| Subject | Re: [PATCH 12/12] mm, page_alloc: Only enforce watermarks for order-0 allocations |
| Message-ID | <qeq5l-6MN-43@gated-at.bofh.it> |
| In reply to | #1235908 |
On 09/30/2015 10:51 AM, Vitaly Wool wrote: > On Wed, Sep 9, 2015 at 2:39 PM, Mel Gorman <mgorman@techsingularity.net> wrote: >> On Tue, Sep 08, 2015 at 05:26:13PM +0900, Joonsoo Kim wrote: >>> 2015-08-24 21:30 GMT+09:00 Mel Gorman <mgorman@techsingularity.net>: >>>> The primary purpose of watermarks is to ensure that reclaim can always >>>> make forward progress in PF_MEMALLOC context (kswapd and direct reclaim). >>>> These assume that order-0 allocations are all that is necessary for >>>> forward progress. >>>> >>>> High-order watermarks serve a different purpose. Kswapd had no high-order >>>> awareness before they were introduced (https://lkml.org/lkml/2004/9/5/9). >>>> This was particularly important when there were high-order atomic requests. >>>> The watermarks both gave kswapd awareness and made a reserve for those >>>> atomic requests. >>>> >>>> There are two important side-effects of this. The most important is that >>>> a non-atomic high-order request can fail even though free pages are available >>>> and the order-0 watermarks are ok. The second is that high-order watermark >>>> checks are expensive as the free list counts up to the requested order must >>>> be examined. >>>> >>>> With the introduction of MIGRATE_HIGHATOMIC it is no longer necessary to >>>> have high-order watermarks. Kswapd and compaction still need high-order >>>> awareness which is handled by checking that at least one suitable high-order >>>> page is free. >>> >>> I still don't think that this one suitable high-order page is enough. >>> If fragmentation happens, there would be no order-2 freepage. If kswapd >>> prepares only 1 order-2 freepage, one of two successive process forks >>> (AFAIK, fork in x86 and ARM require order 2 page) must go to direct reclaim >>> to make order-2 freepage. Kswapd cannot make order-2 freepage in that >>> short time. It causes latency to many high-order freepage requestor >>> in fragmented situation. >>> >> >> So what do you suggest instead? A fixed number, some other heuristic? >> You have pushed several times now for the series to focus on the latency >> of standard high-order allocations but again I will say that it is outside >> the scope of this series. If you want to take steps to reduce the latency >> of ordinary high-order allocation requests that can sleep then it should >> be a separate series. > > I do believe https://lkml.org/lkml/2015/9/9/313 does a better job Does a better job regarding what exactly? It does fix the CMA-specific issue, but so does this patch - without affecting allocation fastpaths by making them update another counter. But the issues discussed here are not related to that CMA problem. > here. I have to admit the patch header is a bit misleading here since > we don't actually exclude CMA pages, we just _fix_ the calculation in > the loop which is utterly wrong otherwise. > > ~vitaly > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Vitaly Wool <vitalywool@gmail.com> |
|---|---|
| Date | 2015-09-30 16:20 +0200 |
| Message-ID | <qeqoG-7qA-27@gated-at.bofh.it> |
| In reply to | #1236320 |
On Wed, Sep 30, 2015 at 3:52 PM, Vlastimil Babka <vbabka@suse.cz> wrote: > On 09/30/2015 10:51 AM, Vitaly Wool wrote: >> >> On Wed, Sep 9, 2015 at 2:39 PM, Mel Gorman <mgorman@techsingularity.net> >> wrote: >>> >>> On Tue, Sep 08, 2015 at 05:26:13PM +0900, Joonsoo Kim wrote: >>>> >>>> 2015-08-24 21:30 GMT+09:00 Mel Gorman <mgorman@techsingularity.net>: >>>>> >>>>> The primary purpose of watermarks is to ensure that reclaim can always >>>>> make forward progress in PF_MEMALLOC context (kswapd and direct >>>>> reclaim). >>>>> These assume that order-0 allocations are all that is necessary for >>>>> forward progress. >>>>> >>>>> High-order watermarks serve a different purpose. Kswapd had no >>>>> high-order >>>>> awareness before they were introduced >>>>> (https://lkml.org/lkml/2004/9/5/9). >>>>> This was particularly important when there were high-order atomic >>>>> requests. >>>>> The watermarks both gave kswapd awareness and made a reserve for those >>>>> atomic requests. >>>>> >>>>> There are two important side-effects of this. The most important is >>>>> that >>>>> a non-atomic high-order request can fail even though free pages are >>>>> available >>>>> and the order-0 watermarks are ok. The second is that high-order >>>>> watermark >>>>> checks are expensive as the free list counts up to the requested order >>>>> must >>>>> be examined. >>>>> >>>>> With the introduction of MIGRATE_HIGHATOMIC it is no longer necessary >>>>> to >>>>> have high-order watermarks. Kswapd and compaction still need high-order >>>>> awareness which is handled by checking that at least one suitable >>>>> high-order >>>>> page is free. >>>> >>>> >>>> I still don't think that this one suitable high-order page is enough. >>>> If fragmentation happens, there would be no order-2 freepage. If kswapd >>>> prepares only 1 order-2 freepage, one of two successive process forks >>>> (AFAIK, fork in x86 and ARM require order 2 page) must go to direct >>>> reclaim >>>> to make order-2 freepage. Kswapd cannot make order-2 freepage in that >>>> short time. It causes latency to many high-order freepage requestor >>>> in fragmented situation. >>>> >>> >>> So what do you suggest instead? A fixed number, some other heuristic? >>> You have pushed several times now for the series to focus on the latency >>> of standard high-order allocations but again I will say that it is >>> outside >>> the scope of this series. If you want to take steps to reduce the latency >>> of ordinary high-order allocation requests that can sleep then it should >>> be a separate series. >> >> >> I do believe https://lkml.org/lkml/2015/9/9/313 does a better job > > > Does a better job regarding what exactly? It does fix the CMA-specific > issue, but so does this patch - without affecting allocation fastpaths by > making them update another counter. But the issues discussed here are not > related to that CMA problem. Let me disagree. Guaranteeing one suitable high-order page is not enough, so the suggested patch does not work that well for me. Existing broken watermark calculation doesn't work for me either, as opposed to the one with my patch applied. Both solutions are related to the CMA issue but one does make compaction work harder and cause bigger latencies -- why do you think these are not related? ~vitaly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Vlastimil Babka <vbabka@suse.cz> |
|---|---|
| Date | 2015-09-30 16:50 +0200 |
| Subject | Re: [PATCH 12/12] mm, page_alloc: Only enforce watermarks for order-0 allocations |
| Message-ID | <qeqRH-7Z1-13@gated-at.bofh.it> |
| In reply to | #1236353 |
On 09/30/2015 04:16 PM, Vitaly Wool wrote: >>>>> >>>> >>>> So what do you suggest instead? A fixed number, some other heuristic? >>>> You have pushed several times now for the series to focus on the latency >>>> of standard high-order allocations but again I will say that it is >>>> outside >>>> the scope of this series. If you want to take steps to reduce the latency >>>> of ordinary high-order allocation requests that can sleep then it should >>>> be a separate series. >>> >>> >>> I do believe https://lkml.org/lkml/2015/9/9/313 does a better job >> >> >> Does a better job regarding what exactly? It does fix the CMA-specific >> issue, but so does this patch - without affecting allocation fastpaths by >> making them update another counter. But the issues discussed here are not >> related to that CMA problem. > > Let me disagree. Guaranteeing one suitable high-order page is not > enough, so the suggested patch does not work that well for me. > Existing broken watermark calculation doesn't work for me either, as > opposed to the one with my patch applied. Both solutions are related > to the CMA issue but one does make compaction work harder and cause > bigger latencies -- why do you think these are not related? Well you didn't mention which issues you have with this patch. If you did measure bigger latencies and more compaction work, please post the numbers and details about the test. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Mel Gorman <mgorman@techsingularity.net> |
|---|---|
| Date | 2015-09-30 17:20 +0200 |
| Subject | Re: [PATCH 12/12] mm, page_alloc: Only enforce watermarks for order-0 allocations |
| Message-ID | <qerkJ-kW-1@gated-at.bofh.it> |
| In reply to | #1236410 |
On Wed, Sep 30, 2015 at 04:43:00PM +0200, Vlastimil Babka wrote: > >>Does a better job regarding what exactly? It does fix the CMA-specific > >>issue, but so does this patch - without affecting allocation fastpaths by > >>making them update another counter. But the issues discussed here are not > >>related to that CMA problem. > > > >Let me disagree. Guaranteeing one suitable high-order page is not > >enough, so the suggested patch does not work that well for me. > >Existing broken watermark calculation doesn't work for me either, as > >opposed to the one with my patch applied. Both solutions are related > >to the CMA issue but one does make compaction work harder and cause > >bigger latencies -- why do you think these are not related? > > Well you didn't mention which issues you have with this patch. If you did > measure bigger latencies and more compaction work, please post the numbers > and details about the test. > And very broadly watch out for decisions that force more reclaim/compaction to potentially reduce latency in the future. It's trading definite overhead now combined with potential reclaim of hot pages to reduce a *possible* high-order allocation request in the future. It's why I think a series that keeps more high-order pages free to reduce future high-order allocation latency needs to be treated with care. -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web