Hi Mel,
Thanks for posting patch. I tested it on LKv4.4.8. Despite
"mode:0x2284020" shows that __GFP_ATOMIC is now not stripped, the
issue remains:
http://pastebin.com/DmezUJSc
Best regards,
Marcin
2016-06-09 20:13 GMT+02:00 Marcin Wojtas :
> Hi Mel,
>
> My last email got cut in half.
>
> 2016-0
Hi Mel,
My last email got cut in half.
2016-06-08 12:09 GMT+02:00 Mel Gorman :
> On Tue, Jun 07, 2016 at 07:36:57PM +0200, Marcin Wojtas wrote:
>> Hi Mel,
>>
>>
>>
>> 2016-06-03 14:36 GMT+02:00 Mel Gorman :
>> > On Fri, Jun 03, 2016 at 01:57:06PM +0200, Marcin Wojtas wrote:
>> >> >> For the recor
On Tue, Jun 07, 2016 at 07:36:57PM +0200, Marcin Wojtas wrote:
> Hi Mel,
>
>
>
> 2016-06-03 14:36 GMT+02:00 Mel Gorman :
> > On Fri, Jun 03, 2016 at 01:57:06PM +0200, Marcin Wojtas wrote:
> >> >> For the record: the newest kernel I was able to reproduce the dumps
> >> >> was v4.6: http://pastebi
Hi Mel,
2016-06-03 14:36 GMT+02:00 Mel Gorman :
> On Fri, Jun 03, 2016 at 01:57:06PM +0200, Marcin Wojtas wrote:
>> >> For the record: the newest kernel I was able to reproduce the dumps
>> >> was v4.6: http://pastebin.com/ekDdACn5. I've just checked v4.7-rc1,
>> >> which comprise a lot (mainly
On Fri, Jun 03, 2016 at 01:57:06PM +0200, Marcin Wojtas wrote:
> >> For the record: the newest kernel I was able to reproduce the dumps
> >> was v4.6: http://pastebin.com/ekDdACn5. I've just checked v4.7-rc1,
> >> which comprise a lot (mainly yours) changes in mm, and I'm wondering
> >> if there ma
Hi Mel,
2016-06-03 11:53 GMT+02:00 Mel Gorman :
> On Thu, Jun 02, 2016 at 09:01:55PM +0200, Marcin Wojtas wrote:
>> >> From what I understood, now order-0 allocation keep no reserve at all.
>> >
>> > Watermarks should still be preserved. zone_watermark_ok is still there.
>> > What might change is
On Thu, Jun 02, 2016 at 09:01:55PM +0200, Marcin Wojtas wrote:
> >> From what I understood, now order-0 allocation keep no reserve at all.
> >
> > Watermarks should still be preserved. zone_watermark_ok is still there.
> > What might change is the size of reserves for high-order atomic
> > allocati
Hi Mel,
2016-06-02 15:52 GMT+02:00 Mel Gorman :
> On Thu, Jun 02, 2016 at 07:48:38AM +0200, Marcin Wojtas wrote:
>> Hi Will,
>>
>> I think I found a right trace. Following one-liner fixes the issue
>> beginning from v4.2-rc1 up to v4.4 included:
>>
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
On Thu, Jun 02, 2016 at 07:48:38AM +0200, Marcin Wojtas wrote:
> Hi Will,
>
> I think I found a right trace. Following one-liner fixes the issue
> beginning from v4.2-rc1 up to v4.4 included:
>
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -294,7 +294,7 @@ static inline bool
> early_page_u
Hi Will,
I think I found a right trace. Following one-liner fixes the issue
beginning from v4.2-rc1 up to v4.4 included:
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -294,7 +294,7 @@ static inline bool
early_page_uninitialised(unsigned long pfn)
static inline bool early_page_nid_uninitialised
On Tue, May 31, 2016 at 01:10:44PM +, Yehuda Yitschak wrote:
> During some of the stress tests we also came across a different warning
> from the arm64 page management code
> It looks like a race is detected between HW and SW marking a bit in the PTE
A72 (which I believe is the CPU in that So
homas Petazzoni; Yehuda
> Yitschak; Catalin Marinas; Arnd Bergmann; Grzegorz Jaszczyk; Will Deacon;
> Nadav Haklai; Tomasz Nowicki; Gregory Clément
> Subject: Re: [BUG] Page allocation failures with newest kernels
>
> Hi Robin,
>
> >
> > I remember there were some issues
Hi Robin,
>
> I remember there were some issues around 4.2 with the revision of the arm64
> atomic implementations affecting the cmpxchg_double() in SLUB, but those
> should all be fixed (and the symptoms tended to be considerably more fatal).
> A stronger candidate would be 97303480753e (which la
On 31/05/16 04:02, Marcin Wojtas wrote:
Hi,
After rebasing platform support of two different ARMv8 SoC's from v4.1
baseline to v4.4 it occurred that stressed systems tend to have page
allocation problems, related to creating new slabs:
http://pastebin.com/FhRW5DsF
Steps to reproduce:
- use SAT
Hi,
After rebasing platform support of two different ARMv8 SoC's from v4.1
baseline to v4.4 it occurred that stressed systems tend to have page
allocation problems, related to creating new slabs:
http://pastebin.com/FhRW5DsF
Steps to reproduce:
- use SATA drive (on-board or over PCIe) with 2 btr
15 matches
Mail list logo
