From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 29 May 2008 19:58:46 -0700 From: Greg KH Subject: Re: [RFC][PATCH 1/2] hugetlb: present information in sysfs Message-ID: <20080530025846.GC6007@kroah.com> References: <20080525142317.965503000@nick.local0.net> <20080525143452.841211000@nick.local0.net> <20080529063915.GC11357@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080529063915.GC11357@us.ibm.com> Sender: owner-linux-mm@kvack.org Return-Path: To: Nishanth Aravamudan Cc: npiggin@suse.de, linux-mm@kvack.org, kniht@us.ibm.com, andi@firstfloor.org, agl@us.ibm.com, abh@cray.com, joachim.deguara@amd.com List-ID: On Wed, May 28, 2008 at 11:39:15PM -0700, Nishanth Aravamudan wrote: > While the procfs presentation of the hstate counters has tried to be as > backwards compatible as possible, I do not believe trying to maintain > all of the information in the same files is a good long-term plan. This > particularly matters for architectures that can support many hugepage > sizes (sparc64 might be one). Even with the three potential pagesizes on > power (64k, 16m and 16g), I found the proc interface to be a little > awkward. > > Instead, migrate the information to sysfs in a new directory, > /sys/kernel/hugepages. Underneath that directory there will be a > directory per-supported hugepage size, e.g.: > > /sys/kernel/hugepages/hugepages-64 > /sys/kernel/hugepages/hugepages-16384 > /sys/kernel/hugepages/hugepages-16777216 > > corresponding to 64k, 16m and 16g respectively. Within each > hugepages-size directory there are a number of files, corresponding to > the tracked counters in the hstate, e.g.: > > /sys/kernel/hugepages/hugepages-64/nr_hugepages > /sys/kernel/hugepages/hugepages-64/nr_overcommit_hugepages > /sys/kernel/hugepages/hugepages-64/free_hugepages > /sys/kernel/hugepages/hugepages-64/resv_hugepages > /sys/kernel/hugepages/hugepages-64/surplus_hugepages > > Of these files, the first two are read-write and the latter three are > read-only. The size of the hugepage being manipulated is trivially > deducible from the enclosing directory and is always expressed in kB (to > match meminfo). > > Signed-off-by: Nishanth Aravamudan > > --- > Nick, I tested this patch and the following one at this point the > series, that is between patches 7 and 8. This does require a few compile > fixes/patch modifications in the later parts of the series. If we decide > that 2/2 is undesirable, there will be fewer of those and 1/2 could also > apply at the end, with less work. I can send you that diff, if you'd > prefer. > > Greg, I didn't hear back from you on the last posting of this patch. Not > intended as a complaint, just an indication of why I didn't make any > changes relative to that version. Does this seem like a reasonable > patch as far as using the sysfs API? I realize a follow-on patch will be > needed to updated Documentation/ABI. I'm sorry, it got lost in the bowels of my inbox, my appologies. This looks fine to me, nice job. And yes, i do want to see the ABI addition as well :) If you add that, feel free to add an: Acked-by: Greg Kroah-Hartman to the patch. thanks, greg k-h -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org