On Thu, Oct 01, 2009 at 04:04:44PM -0400, Jarod Wilson wrote: > On 10/01/2009 11:14 AM, Mel Gorman wrote: >> On Thu, Oct 01, 2009 at 10:18:50AM -0400, Jarod Wilson wrote: > ... >>>> Is it really a good idea fix shmmax as the total of maximum >>>> memory. As this is about hugepages, would a better value for shmmax >>>> be the maximum number of hugepages that can be allocated? i.e. >>>> all statically allocate hugepages + the allower overcommit? >>>> >>>> Similarly, should check_shmmax() warn warn when shmmax is less >>>> than the number of hugepages that can be allocated? >>> >>> This does sound much more sane. However, I'm presently clueless exactly >>> how the max number of hugepages that can be allocated is determined... >> >> Take a look at pool_list() as an example. Use hpool_sizes() to get a list >> of pools configured. Don't bother sorting it, just iterate through the list >> summing up pools[pos].maximum * pools[pos].size. > > Looking at it now... I presume you meant pools[pos].maximum * > pools[pos].pagesize.
Yes, sorry. > So if we were to use this, one couldn't do anything > meaningful with --set-recommended-shmmax until after hugepages had been > allocated, and if more huge pages were later allocated, they would have > to adjust it again. I was sort of gunning for a set-it-and-forget-it > type option, but I suppose its not too unreasonable to expect huge pages > to be configured before we recommend (or set) a shmmax value, and > require reconfiguring if the amount of huge pages changes. > My thinking is that "this is a recommended value for shmmax that is suitable for huge pages". That implies that hugepages are set already and it would need to be documented as such. A fire-and-forget option would be nice but it's hard to guess in advance what a reasonable value for that is . > One minor issue I'm now looking at... If --set-recommended-shmmax is run > without huge pages configured, the recommendation is 0. Presently, I'm > refusing to do anything if I get 0 back. However... If its run after > huge pages have been torn down for some reason, it might be nice to set > shmmax back to the system default. Not sure if 32MB is standard on all > arches/distros/kernels/whatever though, and/or if we should just leave > good enough alone. > Maybe print a warning when it's zero and do nothing further? That would warn the user when they use --set-recommended-shmmax before sizing the huge page pool tool. >>>> 0009-hugeadm-print-note-on-how-to-make-hugetlb_shm_group.patch >>>> >>>> I have similar concertns with this as Patch 6. Maybe it >>>> could be made part of --explain to say how settings >>>> can be persisted? >>> >>> How 'bout we make it an INFO-level print when its actually set, and add >>> spew to --explain for both this and shmmax settings? >>> >> >> Ok, that's reasonable. They'll see the message then with -v but >> otherwise it'll be quiet. >> >>> But if we do, should we go so far as to try to look and see if they have >>> already been added to sysctl.conf, and suppress the message if they >>> have? >> >> I don't think you need to consult sysctl.conf. You could check the >> existing value for the values and only print something if it changes. >> It's easier than sysconf. > > Okay, I'm currently rolling with that. > > Gotta run, but I've got about 99% of an updated patchset together now, > which I'll get out the door tomorrow morning, if not later tonight. > Thoughts on if we should do anything for --set-recommended-shmmax with > no huge pages configured would be appreciated. I'm presently leaning > towards just letting it be. > I think leaving shmmax alone but printing a warning is reasonable. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Libhugetlbfs-devel mailing list Libhugetlbfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
