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

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

 



> From: KY Srinivasan [mailto:kys@xxxxxxxxxxxxx]
> Sent: Monday, November 12, 2012 3:58 PM
> To: David Rientjes
> Cc: gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx;
> olaf@xxxxxxxxx; apw@xxxxxxxxxxxxx; andi@xxxxxxxxxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx; linux-mm@xxxxxxxxx;
> kamezawa.hiroyuki@xxxxxxxxx; mhocko@xxxxxxx; hannes@xxxxxxxxxxx; yinghan@xxxxxxxxxx; Dan Magenheimer
> Subject: RE: [PATCH 1/1] mm: Export a function to read vm_committed_as
> 
> > -----Original Message-----
> > From: David Rientjes [mailto:rientjes@xxxxxxxxxx]
> > Sent: Monday, November 12, 2012 4:54 PM
> > To: KY Srinivasan
> > Cc: gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> > devel@xxxxxxxxxxxxxxxxxxxxxx; olaf@xxxxxxxxx; apw@xxxxxxxxxxxxx;
> > andi@xxxxxxxxxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx; linux-mm@xxxxxxxxx;
> > kamezawa.hiroyuki@xxxxxxxxx; mhocko@xxxxxxx; hannes@xxxxxxxxxxx;
> > yinghan@xxxxxxxxxx
> > Subject: RE: [PATCH 1/1] mm: Export a function to read vm_committed_as
> >
> > On Sun, 11 Nov 2012, KY Srinivasan wrote:
> >
> > > Thanks for the prompt response. For the Linux balloon driver for Hyper-V, I
> > need access
> > > to the metric that reflects the system wide memory commitment made by the
> > guest kernel.
> > > In the Hyper-V case, this information is one of the many metrics used to drive
> > the policy engine
> > > on the host. Granted, the interface name I have chosen here could be more
> > generic; how about
> > > read_mem_commit_info(void). I am open to suggestions here.
> > >
> >
> > I would suggest vm_memory_committed() and there shouldn't be a comment
> > describing that this is just a wrapper for modules to read
> > vm_committed_as, that's apparent from the implementation: it should be
> > describing exactly what this value represents and why it is a useful
> > metric (at least in the case that you're concerned about).
> 
> Will do; thanks.
> >
> > > With regards to making changes to the Xen self ballooning code, I would like to
> > separate that patch
> > > from the patch that implements the exported mechanism to access the
> > memory commitment information.
> >
> > 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@xxxxxxxxxx) 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. :-(

Dan

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]