https://bugzilla.redhat.com/show_bug.cgi?id=604779



시스템이 마치 메모리가 low인 것처럼 행동하고 있습니다. NUMA 관점에서 보면 그렇기 때문입니다.

NUMA에서는, 각 node의 메모리는 다른 node들에 반 독립적으로 관리됩니다.


일단 페이지 요청(page reclamation)이 시작되면, 시스템은 모든 nodes에서 메모리가 더 이상 부족하지 않을 때까지, 

page를 reclaim하는 것을 계속합니다.

우리가 확인한 데이터에서 node 0의 free memory는 min_free_kbytes보다 훨씬 아래에 있습니다.

시스템은 node 0에서의 free memory가 min_free_kbyes 위로 갈 때까지 page recovery를 계속할 것입니다. 

심지어 다른 node들을 희생하며.


이것은 전체적인 total free count가 큰 시스템에 swapping을 발생할 수 있습니다.


memory recovery를 하는 동안, 그것은 각 node에 대해 free memory가 minimum 이상인지 점검할 것입니다. 

모든 node들이 그럴 때까지 계속할 것입니다.

문제는, 그것은 recovery operations을 모든 node에서 수행한다는 것입니다,

심지어 메모리가 low 상태가 아닌 node들도.

이것은 swap out돼서는 안되는 page들이 swap out되는 것을 야기할 수 있습니다.


우리는 하나의 node를, 그 node에서 recovery를 수행하기 전에 점검하도록 하는 upstream 패치를 착수하고 있습니다. 

모든 DMA 메모리는 node 0에 존재하기 때문에, 그리고 메모리 고갈 이슈를 갖는 node이기 때문에, 

ext3 상에서 재현되는지 확인하려고 합니다. 이것은 vxfs가 문제거리가 되는 것을 없앨 수 있을 것입니다.



The system is acting as if it is low on memory, because from a NUMA

(Non-Uniform Memory Architecture) stand point, it is.  In NUMA, memory of

each node is managed semi-independently of the other nodes.


Once page reclamation begins the system continues to reclaim pages until

all nodes are no longer memory starved.  In the data we have looked at the

free memory on node 0 is well below min_free_kbytes.  The system will

continue to preform page recovery until free memory on node 0 is above

min_free_kbytes.  Even at the expense of other nodes.


This can cause swapping on systems where the overall total free count is

huge.


While doing memory recovery, it will check each node to see if free memory

is above the minimum.  It will continue until all nodes are.  The problem

is, it continues to do the recovery operations on all node, even those

that are not low on memory.  This can cause pages to be swapped out that

should not have been.


We are looking at a patch from upstream that checks a node before

performing recovery no that node.  Since all DMA memory does reside in

node 0, and that is the node having memory starvation issues, we would

still like to see if it can be reproduced on ext3.  This could eliminate

vxfs as being a concern here.

+ Recent posts