On 5/13/19 3:14 PM, Andrii Anisov wrote:
Hello Julien,
Hello,
On 13.05.19 14:16, Julien Grall wrote:
I am afraid I can't possible back this assumption. As I pointed out
in the previous version, I would be OK with the always map solution
on Arm32 (pending performance) because it would be possible to
increase the virtual address area by reworking the address space.
I'm sorry, I'm not sure what should be my actions about that.
There no code modification involved so far. Just updating your cover
letter with what I just said above.
OK, I'll take it for the next version.
The patch looks wrong to me. You are using virt_to_phys() on a
percpu area. What does actually promise you the physical address
will always be the same?
Sorry for my ignorance here, could you please elaborate more about
what is wrong here?
While the virtual address will never change over over the life cycle
of a variable, I am not entirely sure we can make the same assumption
for the physical address.
I know that kmalloc() is promising you that the physical address will
not change. But percpu does not seem to use kmalloc() so have you
confirmed this assumption can hold?
I need a bit more time to investigate.
Are you saying that the command dd is the CPUBurn? I am not sure how
this could be considered as a CPUBurn. IHMO, this is more IO related.
Both /dev/null and /dev/zero are virtual devices no actual IO is
performed during their operations, all the load is CPU (user and sys).
Thank you for the explanation. Shall I guess this is an existing
benchmark [1]?
Well, "dd if=/dev/zero of=/dev/null" is just a trivial way to get one rn
CPU core busy. It works for (almost) any Linux system without any
additional movements.
Using another trivial GO application for that purpose, seems to me like
an overkill. Yet if you insist, I can use it.
My point of my message is to understand the exact workload/setup you are
using. "dd" was not an entirely obvious choice for CPUBurn and Google
didn't provide a lot of website backing this information.
Anyway, now I understand a bit more the workload, a couple of more
questions:
- How many vCPUs are you using in each domain?
- What scheduler are you using?
- What is the affinity?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel