On Sat, 17 Mar 2012, Linus Torvalds wrote:
On Sat, Mar 17, 2012 at 3:09 PM, Hugh Dickins hughd@google.com wrote:
I've got to go out for an hour: I'll digest more and think more about this when I get back. If someone could explain the original problem with _MOVABLE, that would help me:
I do not believe we actually ever uncovered the original problem with _MOVABLE: the problem was bisected down to the stable-backported version of commit 4bdadb978569 ("drm/i915: Selectively enable self-reclaim"), and I looked at the changes and decided that one of the main ones was the removal of the mapping_set_gfp_mask() - which resulted in __GFP_MOVABLE being on for the mapping.
So we just tried re-introducing that, and it fixed the problem.
Exactly *why* movable pages are a problem was never all that clear. ...
Thanks a lot for your considered and detailed reply on this (before we added Rafael).
I've come to the (not entirely firm) conclusion that the addition and removal of __GFP_MOVABLE was just shifting the shmem object allocations from one block of memory (shared with others not using __GFP_MOVABLE) to another (shared with others using __GFP_MOVABLE) and back.
So when the __GFP_MOVABLE inadvertently went in, a new group of users who hadn't noticed the corruption before, now reported it; and when you removed the __GFP_MOVABLE (a good idea anyway, pinned pages just clogging up an otherwise movable block of memory), that group of users found their problem solved.
Not really a problem from i915 specifying __GFP_MOVABLE on shmem objects.
Hugh