> -----Original Message----- > From: Michal Hocko [mailto:mstsxfx@xxxxxxxxx] On Behalf Of Michal Hocko > Sent: Tuesday, November 06, 2012 4:06 AM > To: KY Srinivasan > Cc: Andrew Morton; Greg KH; olaf@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > andi@xxxxxxxxxxxxxx; apw@xxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; linux- > mm@xxxxxxxxx; Hiroyuki Kamezawa; Johannes Weiner; Ying Han > Subject: Re: [PATCH 1/2] mm: Export vm_committed_as > > On Mon 05-11-12 22:12:25, KY Srinivasan wrote: > > > > > > > -----Original Message----- > > > From: Andrew Morton [mailto:akpm@xxxxxxxxxxxxxxxxxxxx] > > > Sent: Monday, November 05, 2012 4:45 PM > > > To: KY Srinivasan > > > Cc: Greg KH; olaf@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > andi@xxxxxxxxxxxxxx; > > > apw@xxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; linux-mm@xxxxxxxxx; > > > Hiroyuki Kamezawa; Michal Hocko; Johannes Weiner; Ying Han > > > Subject: Re: [PATCH 1/2] mm: Export vm_committed_as > > > > > > On Sat, 3 Nov 2012 14:09:38 +0000 > > > KY Srinivasan <kys@xxxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > > > > > > > Ok, but you're going to have to get the -mm developers to agree that > > > > > > this is ok before I can accept it. > > > > > > > > > > Well I guess it won't kill us. > > > > > > > > Andrew, > > > > > > > > I presumed this was an Ack from you with regards to exporting the > > > > symbol. Looks like Greg is waiting to hear from you before he can check > > > > these patches in. Could you provide an explicit Ack. > > > > > > > > > > Well, I do have some qualms about exporting vm_committed_as to modules. > > > > > > vm_committed_as is a global thing and only really makes sense in a > > > non-containerised system. If the application is running within a > > > memory cgroup then vm_enough_memory() and the global overcommit > policy > > > are at best irrelevant and misleading. > > > > > > If use of vm_committed_as is indeed a bad thing, then exporting it to > > > modules might increase the amount of badness in the kernel. > > > > > > > > > I don't think these qualms are serious enough to stand in the way of > > > this patch, but I'd be interested in hearing the memcg developers' > > > thoughts on the matter? > > > > > > > > > Perhaps you could provide a detailed description of why your module > > > actually needs this? Precisely what information is it looking for > > > and why? If we know that then perhaps a more comfortable alternative > > > can be found. > > > > The Hyper-V host has a policy engine for managing available physical > > memory across competing virtual machines. This policy decision > > is based on a number of parameters including the memory pressure > > reported by the guest. Currently, the pressure calculation is based > > on the memory commitment made by the guest. From what I can tell, the > > ratio of currently allocated physical memory to the current memory > > commitment made by the guest (vm_committed_as) is used as one of the > > parameters in making the memory balancing decision on the host. This > > is what Windows guests report to the host. So, I need some measure of > > memory commitments made by the Linux guest. This is the reason I want > > export vm_committed_as. > > So IIUC it will be guest who reports the value and the guest runs in the > ring-0 so it is not in any user process context, right? > If this is correct then memcg doesn't play any role here. Thanks Michal. Yes, the kernel driver reports this metric to the host. Andrew, let me know how I should proceed here. Thanks, K. Y _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
