[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 0/2] Introduce runstate area registration with phys address

On 5/13/19 3:14 PM, Andrii Anisov wrote:
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 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?


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.