On Tue 30-07-19 11:05:44, Andrew Morton wrote:
> On Tue, 30 Jul 2019 15:11:27 +0200 Michal Hocko wrote:
>
> > On Thu 23-05-19 17:57:37, Andrew Morton wrote:
> > [...]
> > > It does appear to me that this patch does more good than harm for the
> > > totality of kernel users, so I'm inclined to
On Tue, 30 Jul 2019 15:11:27 +0200 Michal Hocko wrote:
> On Thu 23-05-19 17:57:37, Andrew Morton wrote:
> [...]
> > It does appear to me that this patch does more good than harm for the
> > totality of kernel users, so I'm inclined to push it through and to try
> > to talk Linus out of reverting
On Thu 23-05-19 17:57:37, Andrew Morton wrote:
[...]
> It does appear to me that this patch does more good than harm for the
> totality of kernel users, so I'm inclined to push it through and to try
> to talk Linus out of reverting it again.
What is the status here? I do not see the patch
On Thu, 6 Jun 2019, David Rientjes wrote:
> The idea that I had was snipped from this, however, and it would be nice
> to get some feedback on it: I've suggested that direct reclaim for the
> purposes of hugepage allocation on the local node is never worthwhile
> unless and until memory
On Fri, 7 Jun 2019, Michal Hocko wrote:
> > So my proposed change would be:
> > - give the page allocator a consistent indicator that compaction failed
> >because we are low on memory (make COMPACT_SKIPPED really mean this),
> > - if we get this in the page allocator and we are allocating
On Thu 06-06-19 15:12:40, David Rientjes wrote:
> On Wed, 5 Jun 2019, Michal Hocko wrote:
>
> > > That's fine, but we also must be mindful of users who have used
> > > MADV_HUGEPAGE over the past four years based on its hard-coded behavior
> > > that would now regress as a result.
> >
> >
On Wed, 5 Jun 2019, Michal Hocko wrote:
> > That's fine, but we also must be mindful of users who have used
> > MADV_HUGEPAGE over the past four years based on its hard-coded behavior
> > that would now regress as a result.
>
> Absolutely, I am all for helping those usecases. First of all we
On Fri 31-05-19 14:53:35, David Rientjes wrote:
> On Fri, 31 May 2019, Michal Hocko wrote:
>
> > > The problem which this patch addresses has apparently gone unreported for
> > > 4+ years since
> >
> > Can we finaly stop considering the time and focus on the what is the
> > most reasonable
On Fri, 31 May 2019, Michal Hocko wrote:
> > The problem which this patch addresses has apparently gone unreported for
> > 4+ years since
>
> Can we finaly stop considering the time and focus on the what is the
> most reasonable behavior in general case please? Conserving mistakes
> based on an
On Wed 29-05-19 14:24:33, David Rientjes wrote:
> On Thu, 23 May 2019, Andrew Morton wrote:
>
> > > We are going in circles, *yes* there is a problem for potential swap
> > > storms today because of the poor interaction between memory compaction
> > > and
> > > directed reclaim but this is a
On Thu, 23 May 2019, Andrew Morton wrote:
> > We are going in circles, *yes* there is a problem for potential swap
> > storms today because of the poor interaction between memory compaction and
> > directed reclaim but this is a result of a poor API that does not allow
> > userspace to specify
On Fri, 24 May 2019, Andrea Arcangeli wrote:
> > > We are going in circles, *yes* there is a problem for potential swap
> > > storms today because of the poor interaction between memory compaction
> > > and
> > > directed reclaim but this is a result of a poor API that does not allow
> > >
Hello everyone,
On Thu, May 23, 2019 at 05:57:37PM -0700, Andrew Morton wrote:
> On Mon, 20 May 2019 10:54:16 -0700 (PDT) David Rientjes
> wrote:
>
> > We are going in circles, *yes* there is a problem for potential swap
> > storms today because of the poor interaction between memory
On Mon, May 20, 2019 at 10:54:16AM -0700, David Rientjes wrote:
> On Mon, 20 May 2019, Mel Gorman wrote:
>
> > > There was exhausting discussion subsequent to this that caused Linus to
> > > have to revert the offending commit late in an rc series that is not
> > > described here.
> >
> >
On Mon, 20 May 2019 10:54:16 -0700 (PDT) David Rientjes
wrote:
> We are going in circles, *yes* there is a problem for potential swap
> storms today because of the poor interaction between memory compaction and
> directed reclaim but this is a result of a poor API that does not allow
>
On Mon, 20 May 2019, Mel Gorman wrote:
> > There was exhausting discussion subsequent to this that caused Linus to
> > have to revert the offending commit late in an rc series that is not
> > described here.
>
> Yes, at the crux of that matter was which regression introduced was more
>
On Wed, May 15, 2019 at 01:26:26PM -0700, David Rientjes wrote:
> On Fri, 3 May 2019, Andrea Arcangeli wrote:
>
> > This reverts commit 2f0799a0ffc033bf3cc82d5032acc3ec633464c2.
> >
> > commit 2f0799a0ffc033bf3cc82d5032acc3ec633464c2 was rightfully applied
> > to avoid the risk of a severe
On Fri, 3 May 2019, Andrea Arcangeli wrote:
> This reverts commit 2f0799a0ffc033bf3cc82d5032acc3ec633464c2.
>
> commit 2f0799a0ffc033bf3cc82d5032acc3ec633464c2 was rightfully applied
> to avoid the risk of a severe regression that was reported by the
> kernel test robot at the end of the merge
On Fri, May 03, 2019 at 06:31:46PM -0400, Andrea Arcangeli wrote:
> This reverts commit 2f0799a0ffc033bf3cc82d5032acc3ec633464c2.
>
> commit 2f0799a0ffc033bf3cc82d5032acc3ec633464c2 was rightfully applied
> to avoid the risk of a severe regression that was reported by the
> kernel test robot at
On Fri 03-05-19 18:31:46, Andrea Arcangeli wrote:
> This reverts commit 2f0799a0ffc033bf3cc82d5032acc3ec633464c2.
>
> commit 2f0799a0ffc033bf3cc82d5032acc3ec633464c2 was rightfully applied
> to avoid the risk of a severe regression that was reported by the
> kernel test robot at the end of the
This reverts commit 2f0799a0ffc033bf3cc82d5032acc3ec633464c2.
commit 2f0799a0ffc033bf3cc82d5032acc3ec633464c2 was rightfully applied
to avoid the risk of a severe regression that was reported by the
kernel test robot at the end of the merge window. Now we understood
the regression was a false
21 matches
Mail list logo
