Messages in this thread | | | Date | Thu, 7 Jun 2007 04:10:38 -0400 (EDT) | From | Justin Piszcz <> | Subject | Re: [PATCH] trim memory not covered by WB MTRRs |
| |
On Wed, 6 Jun 2007, Jesse Barnes wrote:
> On Wednesday, June 6, 2007 4:15 pm Justin Piszcz wrote: >> On Wed, 6 Jun 2007, Randy Dunlap wrote: >>> On Wed, 6 Jun 2007 18:54:37 -0400 (EDT) Justin Piszcz wrote: >>>> Hm, not sure if it was from the patch or what but I ran this: >>>> >>>> 1. swapoff -a >>>> 2. ./eatmem >>> >>> You usually have to access the allocated memory, like: >>> >>> *d = 1.0; >>> >>> for it to actually be allocated (AFAIK). >>> >>>> } >>>> >>>> return 0; >>>> } >>>> >>>> Any idea why the OOM killer can or does not kill it? >>> >>> What are the values of /proc/sys/vm/overcommit* ? >>> >>> See Documentation/vm/overcommit-accounting . >> >> They should be the defaults as I do not change them: >> >> p34:~# find /proc/|grep -i overcommit >> /proc/sys/vm/overcommit_memory >> /proc/sys/vm/overcommit_ratio >> find: /proc/5128: No such file or directory >> p34:~# cat /proc/sys/vm/overcommit_memory >> 0 >> p34:~# cat /proc/sys/vm/overcommit_ratio >> 50 >> p34:~# >> >> >> Comments? > > You can be sure your memory is available if reported in /proc/meminfo or > at boot, since those represent the actual kernel data structures used > for memory allocation: > > [ 0.000000] On node 0 totalpages: 2061783 > > That corresponds to 2061783*4k = 8445063168 bytes or ~8053M. Is that > fairly close to what's actually installed in the machine? > > Note that your boot also mentions this: > > [ 106.449661] mtrr: no more MTRRs available > > which indicates that things like X may not be able to map the > framebuffer with the 'write-combine' attribute, which will hurt > performance. I've heard reports that turning of 'Intel QST fan > control' in your BIOS settings will prevent all your MTRRs from being > used (improperly, probably another BIOS bug) so that X will perform > well. But if you don't use X on this machine, you don't have to worry > about it. The other option would be to remap your MTRRs by hand to > free one up for X, you can do that by combining the last one or two > entries into a single MTRR using the API described in > Documentation/mtrr.txt before you start X. > > Jesse >
FYI--
[ 106.449661] mtrr: no more MTRRs available
This has always occurred, even with mem=8832M setting.
Justin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |