On Mon 24-12-12 14:38:50, azurIt wrote:

quoted

OK, good to hear and fingers crossed. I will try to get back to the
original problem and a better solution sometimes early next year when
all the things settle a bit.

Btw, i noticed one more thing when problem is happening (=when any
cgroup is stucked), i fogot to mention it before, sorry :( . It's
related to HDDs, something is slowing them down in a strange way. All
services are working normally and i really cannot notice any slowness,
the only thing which i noticed is affeceted is our backup software (
www.Bacula.org ). When problem occurs at night, so it's happening when
backup is running, backup is extremely slow and usually don't finish
until i kill processes inside affected cgroup (=until i resolve the
problem). Backup software is NOT doing big HDD bandwidth BUT it's
doing quite huge number of disk operations (it needs to stat every
file and directory). I believe that only speed of disk operations are
affected and are very slow.

I would bet that this is caused by the blocked proceses in memcg oom
handler which hold i_mutex and the backup process wants to access the
same inode with an operation which requires the lock.
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>