lkml.org 
[lkml]   [2007]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2007-06-07 10:13    [W:0.492 / U:1.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site