Hello Julien,
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 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.
I did run it until avg more ore less stabilizes (2-3 minutes), then took the
minimal avg (note, we have a moving average there).
Did you re-run multiple time?Yes, sure. These are not the one try results.
--
Sincerely,
Andrii Anisov.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
