[PATCH 1/1] mm: Export a function to read vm_committed_as

[Dan Magenheimer]

> From: KY Srinivasan [mailto:kys at microsoft.com]
> Subject: RE: [PATCH 1/1] mm: Export a function to read vm_committed_as
> 
> > From: David Rientjes [mailto:rientjes at google.com]
> > Sent: Monday, November 12, 2012 6:49 PM
> > To: Dan Magenheimer
> > Cc: KY Srinivasan; Konrad Wilk; gregkh at linuxfoundation.org; linux-
> > kernel at vger.kernel.org; devel at linuxdriverproject.org; olaf at aepfle.de;
> > apw at canonical.com; andi at firstfloor.org; akpm at linux-foundation.org; linux-
> > mm at kvack.org; kamezawa.hiroyuki at gmail.com; mhocko at suse.cz;
> > hannes at cmpxchg.org; yinghan at google.com
> > Subject: RE: [PATCH 1/1] mm: Export a function to read vm_committed_as
> >
> > On Mon, 12 Nov 2012, Dan Magenheimer wrote:
> >
> > > > > Why?  Is xen using it for a different inference?
> > > >
> > > > I think it is good to separate these patches. Dan (copied here) wrote the code
> > for the
> > > > Xen self balloon driver. If it is ok with him I can submit the patch for Xen as
> > well.
> > >
> > > Hi KY --
> > >
> > > If I understand correctly, this would be only a cosmetic (function renaming)
> > change
> > > to the Xen selfballooning code.  If so, then I will be happy to Ack when I
> > > see the patch.  However, Konrad (konrad.wilk at oracle.com) is the maintainer
> > > for all Xen code so you should ask him... and (from previous painful experience)
> > > it can be difficult to sync even very simple interdependent changes going
> > through
> > > different maintainers without breaking linux-next.  So I can't offer any
> > > help with that process, only commiseration. :-(
> > >
> >
> > I think this should be done in the same patch as the function getting
> > introduced with a cc to Konrad and routed through -mm; even better,
> > perhaps he'll have some useful comments for how this is used for xen that
> > can be included for context.
> >
> Ok; I will send out a single patch. I am hoping this can be applied soon as Hyper-V balloon
> driver is queued behind this.
> 
> Regards,
> K. Y

David --

Having caught up on the thread now, I'm a bit confused about your
requirement for KY to patch the Xen selfballooning code.

The data item we are talking about here, committed_as, is defined
by a kernel<->userland ABI, visible to userland via /proc/meminfo.
The Xen selfballoon driver accesses it within the kernel as
a built-in; this driver could potentially be loaded as a
module but currently cannot.

KY is simply asking that the data item be exported so that he can
use it from a new module.  No change to the Xen selfballoon driver
is necessary right now and requiring one only gets in the way of the
patch.  At some future time, the Xen selfballoon driver can, at its
leisure, switch to use the new exported function but need not
unless/until it is capable of being loaded as a module.

And, IIUC, you are asking that KY's proposed new function include a
comment about how it is used by Xen?  How many kernel globals/functions
document at their point of declaration the intent of all the in-kernel
users that use/call them?  That seems a bit unreasonable.  There is a
very long explanatory comment at the beginning of the Xen
selfballoon driver code already.

So I will ack KY's patch (I see it was just sent) but will leave
it up to Konrad and GregKH and Andrew to decide whether to
include the fragment patching the Xen selfballoon driver.

Dan