[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] QEMU bumping memory bug analysis
On Tue, 9 Jun 2015, George Dunlap wrote: > On 06/09/2015 11:14 AM, Stefano Stabellini wrote: > > On Mon, 8 Jun 2015, George Dunlap wrote: > >> I think that qemu needs to tell libxl how much memory it is using for > >> all of its needs -- including option ROMs. (See my example below.) For > >> older qemus we can just make some assumptions like we always have. > > > > I'll just note that I have still not seen any evidence that telling > > libxl would improve things. It seems to me that we are just adding one > > more layer of indirection just to solve the migration issue elsewhere. > > I haven't seen convincing examples that things would be better by telling > > libxl yet, except that we would be able to fix the migration problem. > > So from a migration perspective, I agree there's not much difference > between "libxl reads max_pages from Xen, inserts it into the migration > stream, and sets it again on the other side" and "libxl has global > knowledge of what max_pages should be, inserts it into the migration > stream, and sets it again on the other side". > > Improvements of having it in libxl: > > 1. libxl is not an external interface; we can change and improve things > as we go along. Actually libxl is an external interface, did you mean libxc? > Whatever we put in qemu we have to support indefinitely. The maxmem call is already in QEMU :-) > 2. We can begin to solve the "where is the memory" mess that is the > current state of things. > > 3. In particular, we could conceivably actually change the interface to > be consistent, so that "memory" means "the maximum amount of memory used > by the guest including all overhead", rather than the random who knows > what we have now. That's it, I agree. But the issue is that we don't have a solution or even the design of a solution. If we had, and the plan included reverting the QEMU commit, then fine, let's do it. > This will be impossible if we do it in qemu. > > Having more than one place change max_pages would be poor design even if > we were still packaging everything together in the same release. Having > an external entity with which we must be backwards-compatible change > max_pages it is just a bad idea and always was. I disagree, if it was such an obvious design mistake, more people would have picked up on it immediately when the patch was posted the first time around. This is blurry terrain at best. > > When I committed it, I didn't > > do it without thinking. I don't think that libxl should be in the middle > > of this, because I don't think it has anything to add. > > Just to be clear, nobody thinks you did (at least, as far as I know). > The problem is that all of us are so specialized: some people work > almost entirely within qemu, others in the kernel, others in the > toolstack, others in Xen. It's just natural for people who work mainly > within one component to look at the problem from a particular > perspective. But it causes exactly this sort of problem, where the left > hand doesn't know what the right hand is doing, and the overall system > is really uncoordinated. That is true. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |