On 29 January 2015 at 18:16, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > On Wed, Jan 28, 2015 at 03:32:43PM +0100, Michal Hocko wrote: >> On Wed 28-01-15 08:48:52, Chris Wilson wrote: >> > On Wed, Jan 28, 2015 at 08:13:06AM +1000, Dave Airlie wrote: >> > > https://bugzilla.redhat.com/show_bug.cgi?id=1165369 >> > > >> > > ov 18 09:23:22 elissa.gathman.org kernel: page:f5e36a40 count:2 >> > > mapcount:0 mapping: (null) index:0x0 >> > > Nov 18 09:23:22 elissa.gathman.org kernel: page flags: >> > > 0x80090029(locked|uptodate|lru|swapcache|swapbacked) >> > > Nov 18 09:23:22 elissa.gathman.org kernel: page dumped because: >> > > VM_BUG_ON_PAGE(!lrucare && PageLRU(oldpage)) >> > > Nov 18 09:23:23 elissa.gathman.org kernel: ------------[ cut here ]------------ >> > > Nov 18 09:23:23 elissa.gathman.org kernel: kernel BUG at mm/memcontrol.c:6733! >> >> I guess this matches the following bugon in your kernel: >> VM_BUG_ON_PAGE(!lrucare && PageLRU(oldpage), oldpage); >> >> so the oldpage is on the LRU list already. I am completely unfamiliar >> with 965GM but is the page perhaps shared with somebody with a different >> gfp mask requirement (e.g. userspace accessing the memory via mmap)? So >> the other (racing) caller didn't need to move the page and put it on >> LRU. > > Generally, yes. The shmemfs filp is exported through a vm_mmap() as well > as pinned into the GPU via shmem_read_mapping_page_gfp(). But I would > not expect that to be the case very often, if at all, on 965GM as the > two access paths are incoherent. Still it sounds promising, hopefully > Dave can put it into a fedora kernel for testing? http://kojipkgs.fedoraproject.org/scratch/airlied/task_8760024/ done, also asked on the bug for testers. Dave. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>