search for: mc_debug

This is my current set of updates to Xen for 2.6.24. This is largely a bugfix set, and a couple of them are also relevent to 2.6.23. These are in the pre-x86 merge form; I'll update them once the merge goes into git. Quick overview: - remove some dead code in arch/i386/mm/init.c - clean up some duplicate includes - when sending an IPI, yield the vcpu if the destination doesn't have

This is my current set of updates to Xen for 2.6.24. This is largely a bugfix set, and a couple of them are also relevent to 2.6.23. These are in the pre-x86 merge form; I'll update them once the merge goes into git. Quick overview: - remove some dead code in arch/i386/mm/init.c - clean up some duplicate includes - when sending an IPI, yield the vcpu if the destination doesn't have

This is my current set of updates to Xen for 2.6.24. This is largely a bugfix set, and a couple of them are also relevent to 2.6.23. These are in the pre-x86 merge form; I'll update them once the merge goes into git. Quick overview: - remove some dead code in arch/i386/mm/init.c - clean up some duplicate includes - when sending an IPI, yield the vcpu if the destination doesn't have

...x HPC system that the various readChild() calls in mclapply did not end the children processes, as would be expected (ie compared to what happens on some other Linux machines that I am used to use). Trying to localize the problem, I have recompiled R (R-3.2.5, Intel compilers) after having the 'MC_DEBUG' macro activated in C file src/fork.c. It seems that global variable child_can_exit (declared as static int) is waited for change in function mc_exit but this never happens due to compiler's optimization configuration. A solution might be to declare variable child_can_exit as "static i...

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),

...xed with this commit: https://github.com/wch/r-source/commit/e08cffac1c5b9015a1625938d568b648eb1d8aee Regards, Andreas 2019-11-28 13:54 GMT+01:00 Andreas Kersting<r-devel at akersting.de>: > Hi Tomas, > > I rebuild R (v3.5.2 for now, R-devel to follow) from the Debian package with MC_DEBUG defined and hopefully also with "-Wall -O0 -gdwarf-2 -g3", though I still have to verify this. > > Below is the output. I think it is a total of two mclapply invocations in this R session, the failing one starting around the lines "[1] 15381" and "[1] 15382". Th...

...xed with this commit: https://github.com/wch/r-source/commit/e08cffac1c5b9015a1625938d568b648eb1d8aee Regards, Andreas 2019-11-28 13:54 GMT+01:00 Andreas Kersting<r-devel at akersting.de>: > Hi Tomas, > > I rebuild R (v3.5.2 for now, R-devel to follow) from the Debian package with MC_DEBUG defined and hopefully also with "-Wall -O0 -gdwarf-2 -g3", though I still have to verify this. > > Below is the output. I think it is a total of two mclapply invocations in this R session, the failing one starting around the lines "[1] 15381" and "[1] 15382". Th...

...e back when we know the cause or have it fixed. It would help a lot if you could try with R built from source, with optimizations disabled to get more accurate debug symbols (e.g. env CFLAGS="-Wall -O0 -gdwarf-2 -g3" CXXFLAGS="-Wall -O0 -gdwarf-2 -g3" ./configure), and with MC_DEBUG defined in fork.c - line 26. Ideally in R-devel, so that we are sure the problem still exists. The debug messages should give a hint whether it was R (fork.c) that closed the pipe and why. Maybe you could also add a debug message to close_fds_child_ci() to see if it was closed there. Maybe you...

Hi Linus, Here's a set of patches to update paravirt_ops and Xen for 2.6.24 A quick overview of the patchset: paravirt_ops: Remove the monolithic paravirt_ops structure, and replace it with smaller structures of related functions. Also, clean up the handling of lazy mode to make it easier to implement. x86/mm/init.c: remove a chunk of dead code Xen: - remove duplicate includes -

Hi Linus, Here's a set of patches to update paravirt_ops and Xen for 2.6.24 A quick overview of the patchset: paravirt_ops: Remove the monolithic paravirt_ops structure, and replace it with smaller structures of related functions. Also, clean up the handling of lazy mode to make it easier to implement. x86/mm/init.c: remove a chunk of dead code Xen: - remove duplicate includes -

Hi Linus, Here's a set of patches to update paravirt_ops and Xen for 2.6.24 A quick overview of the patchset: paravirt_ops: Remove the monolithic paravirt_ops structure, and replace it with smaller structures of related functions. Also, clean up the handling of lazy mode to make it easier to implement. x86/mm/init.c: remove a chunk of dead code Xen: - remove duplicate includes -

Hi Andreas, the error is reported when some child process cannot send results to the master process, which originates from an error returned by write() - when write() returns -1 or 0. The logic around the writing has not changed since R 3.5.2. It should not be related to the printing in the child, only to returning the value. The problem may be originating from the execution environment,