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. 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. 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. >>> 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. -- Jarod Wilson ja...@redhat.com ------------------------------------------------------------------------------ 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
