Re: [PATCH v1][RFC] xen balloon driver numa support, libxl interface

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3410 bytes --]

On mar, 2013-08-13 at 21:56 +0100, Ian Campbell wrote:
> On Mon, 2013-08-12 at 17:51 +0200, Dario Faggioli wrote:
> > On lun, 2013-08-12 at 22:57 +0800, Li Yechen wrote:
> > > The relation between virtual and physical node IDs is belong to
> > > another guy's work, I think we could see her email soon. 
> > > 
> > Well, although that's mostly true, I think it would not have harmed to
> > have some sort of high level description of the overall design, trying
> > to explain what the final goal is, who all the involved actors are, what
> > role they play, etc.
> 
> Yechen,
> 
> If there are, as it sounds, several different patches from different
> people within the group needed to implement this feature then please
> could one of you take responsibility for combining them into a single
> (or at most two, one xen.git and one linux.git) coherent series which
> contains everything such that reviewers can get the whole picture.
> 
Yes, Ian, that is pretty much what is going on. Different people working
on different features that are mostly independent but have some
inter-dependencies.

We will definitely put things in such a way that the complete picture
could be available and evident as soon as possible, however, that is not
possible right now.

The reason why Yechen submitted this series, even if a fundamental
building block of it (virtual NUMA topology for guests) is still
missing, is that we thought that there was enough bits of _his_own_work_
--i.e., NUMA-aware ballooning-- in place already, for starting chasing a
bit of feedback, at least on the design of NUMA-aware ballooning itself.

For instance, he has designed it in such a way that it is the higher
toolstack layers (or the user, via xl) that are responsible for deciding
on what physical NUMA node we want some free memory, is that a good
approach? He is doing that by adding a new xenstore node, is that the
right interface? And so on and so forth...

So, basically, we figured that it was worth to try getting an early
enough answer for this kind of questions, especially considering that he
also had some RFC level code that could well exemplify the design
itself. Of course, as other are rightfully pointed out already, when
submitting the RFCs, he failed at describing the complete design, the
motivations and the intended usage of the code he was posting, and we
are sorry and are already addressing this. :-)

To be really honest, I think this is the  biggest issue with this
patches, much more than the fact that some enabling feature/code for it
is still missing. IOW, even if all the bit and pieces were there, it
would be very hard to review the  code without such an high level
explanation of how it is intended to be used anyway, wouldn't it? And as
I said, we're down to fix that.

I hope I clarified the situation at least a bit... In any case, thanks
for having a look at it, and for your suggestion, that I personally
commit to make happen, as soon as all the code will be there (and as
soon as I come back from my summer vacations which are starting in two
days :-P).

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel