On Thu 19-02-15 19:48:16, Tetsuo Handa wrote: > Michal Hocko wrote: [...] > > I do not understand. What kind of bug would be fixed by that change? > > That change fixes significant loss of file I/O reliability under extreme > memory pressure. > > Today I tested how frequent filesystem errors occurs using scripted environment. > ( Source code of a.out is http://marc.info/?l=linux-fsdevel&m=142425860904849&w=2 ) > > ---------- > #!/bin/sh > : > ~/trial.log > for i in `seq 1 100` > do > mkfs.ext4 -q /dev/sdb1 || exit 1 > mount -o errors=remount-ro /dev/sdb1 /tmp || exit 2 > chmod 1777 /tmp > su - demo -c ~demo/a.out > if [ -w /tmp/ ] > then > echo -n "S" >> ~/trial.log > else > echo -n "F" >> ~/trial.log > fi > umount /tmp > done > ---------- > > We can see that filesystem errors are occurring frequently if GFP_NOFS / GFP_NOIO > allocations give up without retrying. I would suggest reporting this to ext people (in a separate thread please) and see what is the proper fix. > On the other hand, as far as these trials, > TIF_MEMDIE stall was not observed if GFP_NOFS / GFP_NOIO allocations give up > without retrying. Maybe giving up without retrying is keeping away from hitting > stalls for this test case? This is expected because those allocations are with locks held and so the chances to release the lock are higher. [...] -- Michal Hocko SUSE Labs -- 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>