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

Re: [Xen-devel] Xen optimization

On Wed, 2018-12-12 at 19:32 +0200, Andrii Anisov wrote:
> On 12.12.18 19:10, Dario Faggioli wrote:
> > I think only bisection could shed some light on this. And it would
> > be
> > wonderful if you could do that, but I understand that it takes
> > time. :-
> > /
> Well, bisect might help. But I'm really confused why MemTotal may be
> reduced.
Yeah, and although difficult to admit/see the reason why, I think this
looks like it is coming from something we do in Xen. And since you say
you have an old Xen version that works, I really see bisection as the
way to go...

> > Are you absolutely sure about that? That is, are you "just"
> > assuming
> > the scheduler won't move stuff, or have you put some debugging or
> > printing in place to verify that to be the case?
> Being honest, I did not check for exactly this setup. I verified it
> for 4.10.
Not sure I'm getting. Are you saying that you somehow verified that on
4.10 vcpus don't move? But on 4.10 you have pinning that works, don't

Or are you saying you've verified that vcpus don't move, on 4.10, even
without doing the pinning? If yes, can I ask how?

As for staging, I really can't tell, as indeed there would be no need
for them to move, but they actually could, for a number of reasons.

So, unless you, like, put printk()-s (if you can) or ASSERTS() when v-
>processor changes, I wouldn't take that for granted. :-(

<<This happens because I choose it to happen!>> (Raistlin Majere)
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

Attachment: signature.asc
Description: This is a digitally signed message part

Xen-devel mailing list



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