[Resending since I messed up the subject, sorry]
Hi, everyone,
Something went wrong between Linux 5.6 and 5.7-rc1. This is an iBook
G4 laptop with 1.5 GiB of RAM running the Debian powerpc port. I
haven't bisected yet, since it's going to take quite a bit of time, so
I'm sending this mostly as a heads-up (and to see if anybody has any
clues about the possible cause). I'm using the following reproducer:
stress-ng --cpu 8 --io 8 --vm 8 --vm-bytes 1G --fork 8 --timeout 10m
On Linux 5.7-rc1, this completely hangs the machine in about 30
seconds. Linux 5.6 survives the test. Let me know if I can provide any
additional info, otherwise I'll just bite the bullet and start
bisecting.
Thanks,
Rui
Hi,
Le 18/05/2020 à 13:20, Rui Salvaterra a écrit :
[Resending since I messed up the subject, sorry]
Hi, everyone,
Something went wrong between Linux 5.6 and 5.7-rc1. This is an iBook
G4 laptop with 1.5 GiB of RAM running the Debian powerpc port. I
haven't bisected yet, since it's going to take quite a bit of time, so
I'm sending this mostly as a heads-up (and to see if anybody has any
clues about the possible cause). I'm using the following reproducer:
stress-ng --cpu 8 --io 8 --vm 8 --vm-bytes 1G --fork 8 --timeout 10m
On Linux 5.7-rc1, this completely hangs the machine in about 30
seconds. Linux 5.6 survives the test. Let me know if I can provide any
additional info, otherwise I'll just bite the bullet and start
bisecting.
Can you provide your .config, tell which GCC version you are using, and
tell a bit more about your config: amount of RAM, is there swap, etc ...
Hi, Christophe,
On Mon, 18 May 2020 at 12:50, Christophe Leroy
[off-list ref] wrote:
Can you provide your .config, tell which GCC version you are using, and
tell a bit more about your config: amount of RAM, is there swap, etc ...
Ok, so this laptop has 1.5 GiB of RAM, with swap on zram (zstd
compression, no backing device, no additional swap devices). I'm
cross-compiling on my dual-core Power Mac G5 (since it's much faster
than the iBook), running Debian ppc64, with GCC 9.3.0. Both 5.6 (good)
and 5.7-rc1 (bad) configs are attached.
Thanks,
Rui
Hi, Christophe,
On Mon, 18 May 2020 at 12:50, Christophe Leroy
[off-list ref] wrote:
quoted
Can you provide your .config, tell which GCC version you are using, and
tell a bit more about your config: amount of RAM, is there swap, etc ...
Ok, so this laptop has 1.5 GiB of RAM, with swap on zram (zstd
compression, no backing device, no additional swap devices). I'm
cross-compiling on my dual-core Power Mac G5 (since it's much faster
than the iBook), running Debian ppc64, with GCC 9.3.0. Both 5.6 (good)
and 5.7-rc1 (bad) configs are attached.
Can you try reverting 697ece78f8f749aeea40f2711389901f0974017a ? It may
have broken swap.
Christophe
Hi again, Christophe,
On Mon, 18 May 2020 at 15:03, Christophe Leroy
[off-list ref] wrote:
quoted
Can you try reverting 697ece78f8f749aeea40f2711389901f0974017a ? It may
have broken swap.
Yeah, that was a good call. :) Linux 5.7-rc1 with the revert on top
survives the beating. I'll be happy to test a definitive patch!
Yeah I discovered recently that the way swap is implemented on powerpc
expects RW and other important bits not be one of the 3 least
significant bits (see __pte_to_swp_entry() )
I guess the easiest for the time being is to revert the commit with a
proper explanation of the issue, then one day we'll modify the way
powerpc manages swap.
Christophe
On Mon, 18 May 2020 at 18:15, Christophe Leroy
[off-list ref] wrote:
Yeah I discovered recently that the way swap is implemented on powerpc
expects RW and other important bits not be one of the 3 least
significant bits (see __pte_to_swp_entry() )
I see, you get the swap entry by shifting the PTE right three bits.
I guess the easiest for the time being is to revert the commit with a
proper explanation of the issue, then one day we'll modify the way
powerpc manages swap.
I wonder, what issues could be observable by reverting? I'm asking
this because I've seen another hang on Linux 5.6, but it's harder to
trigger and it involves the GPU (I usually reproduce it easily by,
say, running Arctic Fox and starting a simple OpenGL game like
Chromium BSU). Of course, since this is PowerPC with AGP (even though
I have the AGP GART disabled), it's most likely something unrelated.
Hi again, Christophe,
On Mon, 18 May 2020 at 15:03, Christophe Leroy
[off-list ref] wrote:
quoted
Can you try reverting 697ece78f8f749aeea40f2711389901f0974017a ? It may
have broken swap.
Yeah, that was a good call. :) Linux 5.7-rc1 with the revert on top
survives the beating. I'll be happy to test a definitive patch!
Yeah I discovered recently that the way swap is implemented on powerpc
expects RW and other important bits not be one of the 3 least
significant bits (see __pte_to_swp_entry() )
The last 3 bits are there to track the _PAGE_PRESENT right? What is the
RW dependency there? Are you suggesting of read/write migration entry?
A swap entry should not retain the pte rw bits right?
A swap entry is built using swap type + offset. And it should not have a
dependency on pte RW bits. Along with type and offset we also should
have the ability to mark it as a pte entry and also set not present
bits. With that understanding what am I missing here?
I guess the easiest for the time being is to revert the commit with a
proper explanation of the issue, then one day we'll modify the way
powerpc manages swap.
Hi again, Christophe,
On Mon, 18 May 2020 at 15:03, Christophe Leroy
[off-list ref] wrote:
quoted
Can you try reverting 697ece78f8f749aeea40f2711389901f0974017a ? It may
have broken swap.
Yeah, that was a good call. :) Linux 5.7-rc1 with the revert on top
survives the beating. I'll be happy to test a definitive patch!
Yeah I discovered recently that the way swap is implemented on powerpc
expects RW and other important bits not be one of the 3 least
significant bits (see __pte_to_swp_entry() )
The last 3 bits are there to track the _PAGE_PRESENT right? What is the
RW dependency there? Are you suggesting of read/write migration entry?
A swap entry should not retain the pte rw bits right?
A swap entry is built using swap type + offset. And it should not have a
dependency on pte RW bits. Along with type and offset we also should
have the ability to mark it as a pte entry and also set not present
bits. With that understanding what am I missing here?
That's probably me who is missing something, I have not digged into the
swap functionning yet indeed, so that was only my first feeling.
By the way, the problems is definitely due to the order changes in the
PTE bits, whether that's because _PAGE_RW was moved to the last 3 bits
or whether that's because _PAGE_PRESENT was moved out of the last 3
bits, I don't know yet.
My (bad) understanding is from the fact that __pte_to_swp_entry() is a
right shift by 3 bits, so it looses the last 3 bits, and therefore
__swp_entry_to_pte(__pte_to_swp_entry(pte)) looses the last 3 bits of a PTE.
Is there somewhere a description of how swap works exactly ?
Christophe
Hi again, Christophe,
On Mon, 18 May 2020 at 15:03, Christophe Leroy
[off-list ref] wrote:
quoted
Can you try reverting 697ece78f8f749aeea40f2711389901f0974017a ? It
may
have broken swap.
Yeah, that was a good call. :) Linux 5.7-rc1 with the revert on top
survives the beating. I'll be happy to test a definitive patch!
Yeah I discovered recently that the way swap is implemented on powerpc
expects RW and other important bits not be one of the 3 least
significant bits (see __pte_to_swp_entry() )
The last 3 bits are there to track the _PAGE_PRESENT right? What is the
RW dependency there? Are you suggesting of read/write migration entry?
A swap entry should not retain the pte rw bits right?
A swap entry is built using swap type + offset. And it should not have a
dependency on pte RW bits. Along with type and offset we also should
have the ability to mark it as a pte entry and also set not present
bits. With that understanding what am I missing here?
That's probably me who is missing something, I have not digged into the
swap functionning yet indeed, so that was only my first feeling.
By the way, the problems is definitely due to the order changes in the
PTE bits, whether that's because _PAGE_RW was moved to the last 3 bits
or whether that's because _PAGE_PRESENT was moved out of the last 3
bits, I don't know yet.
My (bad) understanding is from the fact that __pte_to_swp_entry() is a
right shift by 3 bits, so it looses the last 3 bits, and therefore
__swp_entry_to_pte(__pte_to_swp_entry(pte)) looses the last 3 bits of a
PTE.
Is there somewhere a description of how swap works exactly ?
Looking at __set_pte_at(), I am wondering whether this was due to
_PAGE_HASHPTE? . This would mean we end up wrongly updating some swap
entry details. We call set_pte_at() on swap pte entries.
-aneesh