On Saturday 08 November 2014, Vlastimil Babka wrote:
> >From fbf8eb0bcd2897090312e23da6a31bad9cc6b337 Mon Sep 17 00:00:00 2001
>
> From: Vlastimil Babka
> Date: Sat, 8 Nov 2014 22:20:43 +0100
> Subject: [PATCH] mm, compaction: prevent endless loop in migrate scanner
After 30hrs uptime, I also ma
On Mon, Nov 10, 2014 at 08:53:38AM +0100, Vlastimil Babka wrote:
> On 11/10/2014 07:07 AM, Joonsoo Kim wrote:
> >On Sat, Nov 08, 2014 at 11:18:37PM +0100, Vlastimil Babka wrote:
> >>On 11/08/2014 02:11 PM, P. Christeas wrote:
> >>
> >>Hi,
> >>
> >>I think I finally found the cause by staring into t
On 11/10/2014 07:07 AM, Joonsoo Kim wrote:
On Sat, Nov 08, 2014 at 11:18:37PM +0100, Vlastimil Babka wrote:
On 11/08/2014 02:11 PM, P. Christeas wrote:
Hi,
I think I finally found the cause by staring into the code... CCing
people from all 4 separate threads I know about this issue.
The proble
On Sat, Nov 08, 2014 at 11:18:37PM +0100, Vlastimil Babka wrote:
> On 11/08/2014 02:11 PM, P. Christeas wrote:
> > On Thursday 06 November 2014, Vlastimil Babka wrote:
> >>> On Wednesday 05 November 2014, Vlastimil Babka wrote:
> Can you please try the following patch?
> -
> >
> > I guess this one would mitigate against Vlastmil's migration scanner issue,
> > wouldn't it?
>
Nope, I wanted to see if free pages are low enough.
> Please no, that's a wrong fix. The purpose of compaction is to make the
> high-order watermark meet, not give up.
>
Yupe, have to spin.
-
Hi Vlastimil, hi all,
On Sun, 09 Nov 2014, Vlastimil Babka wrote:
> I don't want to send untested fix, and wasn't able to reproduce the bug
> myself. I think Norbert could do it rather quickly so I hope he can tell
> us soon.
Sorry, weekend means I am away from my laptop for extended times,
and I
On 11/09/2014 09:27 AM, Pavel Machek wrote:
> Hi!
>
Oh and did I ask in this thread for /proc/zoneinfo yet? :)
>>>
>>> Using that same kernel[1], got again into a race, gathered a few more data.
>>>
>>> This time, I had 1x "urpmq" process [2] hung at 100% CPU , when "kwin" got
>>> apparently
On 11/09/2014 09:22 AM, P. Christeas wrote:
> On Sunday 09 November 2014, Hillf Danton wrote:
>> -return COMPACT_CONTINUE;
>> +return COMPACT_SKIPPED;
>
> I guess this one would mitigate against Vlastmil's migration scanner issue,
> wouldn't it?
Please no, that's a wrong
Hi!
> >> Oh and did I ask in this thread for /proc/zoneinfo yet? :)
> >
> > Using that same kernel[1], got again into a race, gathered a few more data.
> >
> > This time, I had 1x "urpmq" process [2] hung at 100% CPU , when "kwin" got
> > apparently blocked (100% CPU, too) trying to resize a GU
On Sunday 09 November 2014, Hillf Danton wrote:
> - return COMPACT_CONTINUE;
> + return COMPACT_SKIPPED;
I guess this one would mitigate against Vlastmil's migration scanner issue,
wouldn't it?
In that case, I should wait a bit[1] to try the first patch, then revert, try
> > Can you please try the following patch?
> > --- a/mm/compaction.c
> > +++ b/mm/compaction.c
> > @@ -1325,13 +1325,6 @@ unsigned long try_to_compact_pages(struct zonelist
> > - compaction_defer_reset(zone, order, false);
>
> NACK :(
>
> I just got again into a state that some
On 11/08/2014 02:11 PM, P. Christeas wrote:
> On Thursday 06 November 2014, Vlastimil Babka wrote:
>>> On Wednesday 05 November 2014, Vlastimil Babka wrote:
Can you please try the following patch?
- compaction_defer_reset(zone, order, false);
>> Oh and did I ask in this t
On Thursday 06 November 2014, Vlastimil Babka wrote:
> > On Wednesday 05 November 2014, Vlastimil Babka wrote:
> >> Can you please try the following patch?
> >> - compaction_defer_reset(zone, order, false);
> Oh and did I ask in this thread for /proc/zoneinfo yet? :)
Using that sa
On 11/06/2014 08:23 PM, P. Christeas wrote:
> On Wednesday 05 November 2014, Vlastimil Babka wrote:
>> Can you please try the following patch?
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -1325,13 +1325,6 @@ unsigned long try_to_compact_pages(struct zonelist
>> -compa
On Wednesday 05 November 2014, Vlastimil Babka wrote:
> Can you please try the following patch?
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1325,13 +1325,6 @@ unsigned long try_to_compact_pages(struct zonelist
> - compaction_defer_reset(zone, order, false);
NACK :(
I
On Wednesday 05 November 2014, Vlastimil Babka wrote:
> I see. I've tried to reproduce such issues with 3.18-rc3 but wasn't
> successful. But I noticed a possible issue that could lead to your problem.
> Can you please try the following patch?
OK, I can give it a try.
FYI, the "stability canary"
On 11/04/2014 10:36 AM, P. Christeas wrote:
> On Tuesday 04 November 2014, Vlastimil Babka wrote:
>> Please do keep testing (and see below what we need), and don't try
>> another tree - it's 3.18 we need to fix!
> Let me apologize/warn you about the poor quality of this report (and debug
> data).
On Tuesday 04 November 2014, Vlastimil Babka wrote:
> Please do keep testing (and see below what we need), and don't try
> another tree - it's 3.18 we need to fix!
Let me apologize/warn you about the poor quality of this report (and debug
data).
It is on a system meant for everyday desktop usage,
On 11/04/2014 08:26 AM, P. Christeas wrote:
TL;DR: I'm testing Linus's 3.18-rcX in my desktop (x86_64, full load),
experiencing mm races about every day. Current -rc starves the canary of
stablity
Will keep testing (should I try some -mm tree, please? ) , provide you
feedback about the issue.
19 matches
Mail list logo
