On Thursday 06 November 2014, Vlastimil Babka wrote:
> > On Wednesday 05 November 2014, Vlastimil Babka wrote:
> >> Can you please try the following patch?
> >> -			compaction_defer_reset(zone, order, false);
> Oh and did I ask in this thread for /proc/zoneinfo yet? :)

Using that same kernel[1], got again into a race, gathered a few more data.

This time, I had 1x "urpmq" process [2] hung at 100% CPU , when "kwin" got 
apparently blocked (100% CPU, too) trying to resize a GUI window. I suppose 
the resizing operation would mean heavy memory alloc/free.

The rest of the system was responsive, I could easily get a console, login, 
gather the files.. Then, I have *killed* -9 the "urpmq" process, which solved 
the race and my system is still alive! "kwin" is still running, returned to 
regular CPU load.

Attached is traces from SysRq+l (pressed a few times, wanted to "snapshot" the 
stack) and /proc/zoneinfo + /proc/vmstat

Bisection is not yet meaningful, IMHO, because I cannot be sure that "good" 
points are really free from this issue. I'd estimate that each test would take 
+3days, unless I really find a deterministic way to reproduce the issue .


Thank you, again.


[1] linus's didn't have any -mm changes, so I haven't compiled anything yet. 
This means it also contains the "- compaction_defer_reset()" change

[2] urpmq is a Mandrake distro Perl script for querying the RPM database. It 
does some disk I/O , loads data into allocated Perl structs and sorts that, 
FYI.