Re: How to handle TIF_MEMDIE stalls?

Michal Hocko
2015-02-20T08:26:07Z

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