On Mon, Jul 11, 2016 at 04:01:52PM -0700, David Rientjes wrote:
> On Thu, 30 Jun 2016, Joonsoo Kim wrote:
>
> > We need to find a root cause of this problem, first.
> >
> > I guess that this problem would happen when isolate_freepages_block()
> > early stop due to watermark check (if your patch
On Mon, Jul 11, 2016 at 04:01:52PM -0700, David Rientjes wrote:
> On Thu, 30 Jun 2016, Joonsoo Kim wrote:
>
> > We need to find a root cause of this problem, first.
> >
> > I guess that this problem would happen when isolate_freepages_block()
> > early stop due to watermark check (if your patch
On Thu, 30 Jun 2016, Joonsoo Kim wrote:
> We need to find a root cause of this problem, first.
>
> I guess that this problem would happen when isolate_freepages_block()
> early stop due to watermark check (if your patch is applied to your
> kernel). If scanner meets, cached pfn will be reset and
On Thu, 30 Jun 2016, Joonsoo Kim wrote:
> We need to find a root cause of this problem, first.
>
> I guess that this problem would happen when isolate_freepages_block()
> early stop due to watermark check (if your patch is applied to your
> kernel). If scanner meets, cached pfn will be reset and
On Thu, Jun 30, 2016 at 09:42:36AM +0200, Vlastimil Babka wrote:
> On 06/30/2016 09:31 AM, Joonsoo Kim wrote:
> >On Wed, Jun 29, 2016 at 01:55:55PM -0700, David Rientjes wrote:
> >>On Wed, 29 Jun 2016, Vlastimil Babka wrote:
> >>
> >>>On 06/29/2016 03:39 AM, David Rientjes wrote:
> It's
On Thu, Jun 30, 2016 at 09:42:36AM +0200, Vlastimil Babka wrote:
> On 06/30/2016 09:31 AM, Joonsoo Kim wrote:
> >On Wed, Jun 29, 2016 at 01:55:55PM -0700, David Rientjes wrote:
> >>On Wed, 29 Jun 2016, Vlastimil Babka wrote:
> >>
> >>>On 06/29/2016 03:39 AM, David Rientjes wrote:
> It's
On Wed, Jun 29, 2016 at 01:55:55PM -0700, David Rientjes wrote:
> On Wed, 29 Jun 2016, Vlastimil Babka wrote:
>
> > On 06/29/2016 03:39 AM, David Rientjes wrote:
> > > It's possible that the freeing scanner can be consistently expensive if
> > > memory is well compacted toward the end of the zone
On Wed, Jun 29, 2016 at 01:55:55PM -0700, David Rientjes wrote:
> On Wed, 29 Jun 2016, Vlastimil Babka wrote:
>
> > On 06/29/2016 03:39 AM, David Rientjes wrote:
> > > It's possible that the freeing scanner can be consistently expensive if
> > > memory is well compacted toward the end of the zone
On 06/30/2016 09:31 AM, Joonsoo Kim wrote:
On Wed, Jun 29, 2016 at 01:55:55PM -0700, David Rientjes wrote:
On Wed, 29 Jun 2016, Vlastimil Babka wrote:
On 06/29/2016 03:39 AM, David Rientjes wrote:
It's possible that the freeing scanner can be consistently expensive if
memory is well
On 06/30/2016 09:31 AM, Joonsoo Kim wrote:
On Wed, Jun 29, 2016 at 01:55:55PM -0700, David Rientjes wrote:
On Wed, 29 Jun 2016, Vlastimil Babka wrote:
On 06/29/2016 03:39 AM, David Rientjes wrote:
It's possible that the freeing scanner can be consistently expensive if
memory is well
On Wed, 29 Jun 2016, Vlastimil Babka wrote:
> On 06/29/2016 03:39 AM, David Rientjes wrote:
> > It's possible that the freeing scanner can be consistently expensive if
> > memory is well compacted toward the end of the zone with few free pages
> > available in that area.
> >
> > If all zone
On Wed, 29 Jun 2016, Vlastimil Babka wrote:
> On 06/29/2016 03:39 AM, David Rientjes wrote:
> > It's possible that the freeing scanner can be consistently expensive if
> > memory is well compacted toward the end of the zone with few free pages
> > available in that area.
> >
> > If all zone
On 06/29/2016 03:39 AM, David Rientjes wrote:
It's possible that the freeing scanner can be consistently expensive if
memory is well compacted toward the end of the zone with few free pages
available in that area.
If all zone memory is synchronously compacted, say with
On 06/29/2016 03:39 AM, David Rientjes wrote:
It's possible that the freeing scanner can be consistently expensive if
memory is well compacted toward the end of the zone with few free pages
available in that area.
If all zone memory is synchronously compacted, say with
It's possible that the freeing scanner can be consistently expensive if
memory is well compacted toward the end of the zone with few free pages
available in that area.
If all zone memory is synchronously compacted, say with
/proc/sys/vm/compact_memory, and thp is faulted, it is possible to
It's possible that the freeing scanner can be consistently expensive if
memory is well compacted toward the end of the zone with few free pages
available in that area.
If all zone memory is synchronously compacted, say with
/proc/sys/vm/compact_memory, and thp is faulted, it is possible to
16 matches
Mail list logo
