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

[Andrii Anisov <andrii.anisov@xxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel