a heavy-weight page migration has happened on the
page fault.
If that is possible, can you please update the documentation and list
the flags that are permitted in the callback's return value?
Thanks!
--
Evgeny Baskakov
NVIDIA
a heavy-weight page migration has happened on the
page fault.
If that is possible, can you please update the documentation and list
the flags that are permitted in the callback's return value?
Thanks!
--
Evgeny Baskakov
NVIDIA
observed seem to be gone!
I am still running my stress tests, though. I will let you know if there
is anything else that needs to be addressed.
Thanks!
--
Evgeny Baskakov
NVIDIA
observed seem to be gone!
I am still running my stress tests, though. I will let you know if there
is anything else that needs to be addressed.
Thanks!
--
Evgeny Baskakov
NVIDIA
=,
dst=, private=0xc900037439c0) at mm/migrate.c:2844
Please find another reproducer attached (sanity_rmem004_execve.tgz) for
this issue.
Thanks!
--
Evgeny Baskakov
NVIDIA
sanity_rmem004_execve.tgz
Description: GNU Zip compressed data
sanity_rmem004_fork.tgz
Description: GNU Zip compressed data
=,
dst=, private=0xc900037439c0) at mm/migrate.c:2844
Please find another reproducer attached (sanity_rmem004_execve.tgz) for
this issue.
Thanks!
--
Evgeny Baskakov
NVIDIA
sanity_rmem004_execve.tgz
Description: GNU Zip compressed data
sanity_rmem004_fork.tgz
Description: GNU Zip compressed data
On 7/10/17 5:54 PM, Jerome Glisse wrote:
On Mon, Jul 10, 2017 at 05:17:23PM -0700, Evgeny Baskakov wrote:
On 7/10/17 4:43 PM, Jerome Glisse wrote:
On Mon, Jul 10, 2017 at 03:59:37PM -0700, Evgeny Baskakov wrote:
...
Horrible stupid bug in the code, most likely from cut and paste. Attached
On 7/10/17 5:54 PM, Jerome Glisse wrote:
On Mon, Jul 10, 2017 at 05:17:23PM -0700, Evgeny Baskakov wrote:
On 7/10/17 4:43 PM, Jerome Glisse wrote:
On Mon, Jul 10, 2017 at 03:59:37PM -0700, Evgeny Baskakov wrote:
...
Horrible stupid bug in the code, most likely from cut and paste. Attached
it).
Thanks!
--
Evgeny Baskakov
NVIDIA
it).
Thanks!
--
Evgeny Baskakov
NVIDIA
mp;& 1 migrate threads: PASSED
(OK)[./sanity_rmem004] anon migration read test
Thanks,
--
Evgeny Baskakov
NVIDIA
mp;& 1 migrate threads: PASSED
(OK)[./sanity_rmem004] anon migration read test
Thanks,
--
Evgeny Baskakov
NVIDIA
and
HMM_DMIRROR_MIGRATE requests eventually succeed. See comments in the
hmm_test() function.
Thanks!
--
Evgeny Baskakov
NVIDIA
sanity_rmem004_repeated_faults_threaded_notallocated.tgz
Description: GNU Zip compressed data
and
HMM_DMIRROR_MIGRATE requests eventually succeed. See comments in the
hmm_test() function.
Thanks!
--
Evgeny Baskakov
NVIDIA
sanity_rmem004_repeated_faults_threaded_notallocated.tgz
Description: GNU Zip compressed data
issues here.
Jérôme
That is correct, the program is not making any progress.
The stack traces in the kernel log are produced by a "sysrq w" (blocked
tasks) command.
Thanks,
--
Evgeny Baskakov
NVIDIA
issues here.
Jérôme
That is correct, the program is not making any progress.
The stack traces in the kernel log are produced by a "sysrq w" (blocked
tasks) command.
Thanks,
--
Evgeny Baskakov
NVIDIA
. Please find attached a new kernel log and an app log.
--
Evgeny Baskakov
NVIDIA
sanity_rmem004_repeated_faults_threaded$ ./run.sh
&&& 2 migrate threads, 2 read threads: STARTING
iteration 0
iteration 1
iteration 2
iteration 3
iteration 4
iteration 5
iteration 6
iteration 7
iterat
. Please find attached a new kernel log and an app log.
--
Evgeny Baskakov
NVIDIA
sanity_rmem004_repeated_faults_threaded$ ./run.sh
&&& 2 migrate threads, 2 read threads: STARTING
iteration 0
iteration 1
iteration 2
iteration 3
iteration 4
iteration 5
iteration 6
iteration 7
iterat
On 7/10/17 4:43 PM, Jerome Glisse wrote:
On Mon, Jul 10, 2017 at 03:59:37PM -0700, Evgeny Baskakov wrote:
...
Horrible stupid bug in the code, most likely from cut and paste. Attached
patch should fix it. I don't know how long it took for you to trigger it.
Jérôme
Thanks, this indeed fixes
On 7/10/17 4:43 PM, Jerome Glisse wrote:
On Mon, Jul 10, 2017 at 03:59:37PM -0700, Evgeny Baskakov wrote:
...
Horrible stupid bug in the code, most likely from cut and paste. Attached
patch should fix it. I don't know how long it took for you to trigger it.
Jérôme
Thanks, this indeed fixes
139.055145] SyS_ioctl+0x79/0x90
[ 139.055148] entry_SYSCALL_64_fastpath+0x13/0x94
Please compile and run the attached program this way:
$ ./build.sh
$ sudo ./kload.sh
$ sudo ./run.sh
Thanks!
Evgeny Baskakov
NVIDIA
sanity_rmem004_repeated_faults_threaded.tgz
Description: GNU Zip compressed
139.055145] SyS_ioctl+0x79/0x90
[ 139.055148] entry_SYSCALL_64_fastpath+0x13/0x94
Please compile and run the attached program this way:
$ ./build.sh
$ sudo ./kload.sh
$ sudo ./run.sh
Thanks!
Evgeny Baskakov
NVIDIA
sanity_rmem004_repeated_faults_threaded.tgz
Description: GNU Zip compressed
?
Here's a command to reproduce, using the kload.sh script (taken from a
sanity suite you provided earlier, attached):
$ while true; do sudo ./kload.sh; done
Thanks!
Evgeny Baskakov
NVIDIA
kload.sh
Description: Bourne shell script
and to reproduce, using the kload.sh script (taken from a
sanity suite you provided earlier, attached):
$ while true; do sudo ./kload.sh; done
Thanks!
Evgeny Baskakov
NVIDIA
kload.sh
Description: Bourne shell script
On 6/30/17 5:57 PM, Jerome Glisse wrote:
On Fri, Jun 30, 2017 at 04:19:25PM -0700, Evgeny Baskakov wrote:
Hi Jerome,
It seems that the kernel can pass 0 in src_pfns for pages that it cannot
migrate (i.e. the kernel knows that they cannot migrate prior to calling
alloc_and_copy).
So, a zero
On 6/30/17 5:57 PM, Jerome Glisse wrote:
On Fri, Jun 30, 2017 at 04:19:25PM -0700, Evgeny Baskakov wrote:
Hi Jerome,
It seems that the kernel can pass 0 in src_pfns for pages that it cannot
migrate (i.e. the kernel knows that they cannot migrate prior to calling
alloc_and_copy).
So, a zero
On 6/26/17 5:07 PM, Evgeny Baskakov wrote:
> Hi Jerome,
>
> The documentation shown above doesn't tell what the alloc_and_copy
callback should do for source pages that have not been allocated yet.
Instead, it unconditionally suggests checking if the MIGRATE_PFN_VALID
and MIGRATE_PF
On 6/26/17 5:07 PM, Evgeny Baskakov wrote:
> Hi Jerome,
>
> The documentation shown above doesn't tell what the alloc_and_copy
callback should do for source pages that have not been allocated yet.
Instead, it unconditionally suggests checking if the MIGRATE_PFN_VALID
and MIGRATE_PF
ke to suggest reflecting that in the documentation. Or, which would
be more logical, migrate_vma could keep the zero in the PFN entries for not
allocated pages, but set the MIGRATE_PFN_MIGRATE flag anyway.
Thanks!
Evgeny Baskakov
NVIDIA
ke to suggest reflecting that in the documentation. Or, which would
be more logical, migrate_vma could keep the zero in the PFN entries for not
allocated pages, but set the MIGRATE_PFN_MIGRATE flag anyway.
Thanks!
Evgeny Baskakov
NVIDIA
30 matches
Mail list logo
