mem_cgroup_force_empty_list() executed in workqueue context. If work doesn't
go to sleep the workqueue engine thinks that this work is making progress,
so there is no need to start more workers to execute other works.
So, if we need other works to be executed to unlock those pages we might
have a
On 09/05/2017 04:26 PM, Vasily Averin wrote:
Kostja,
why it changes autofs_sb_info?
this hook looks unrelated to the problem
and first hook in fs/autofs4/inode.c too.
The patch rolls back hunks of our patch,
all those hunks are not needed now.
Bug is fixed by only 2 last hunks, agree, i wrote
Kostja,
why it changes autofs_sb_info?
this hook looks unrelated to the problem
and first hook in fs/autofs4/inode.c too.
On 2017-09-05 15:47, Konstantin Khorenko wrote:
> Please consider to prepare a ReadyKernel patch for it.
>
> This is needed for all kernels prior to 3.10.0-693.x
>
> https://
We have a problem on several our nodes with scsi EH. Imagine such an
order of execution of two threads:
CPU1 scsi_eh_scmd_add CPU2 scsi_host_queue_ready
/* shost->host_busy == 1 initialy */
if (shost->shost_state == SHOST_RECOVERY)
Please consider to prepare a ReadyKernel patch for it.
This is needed for all kernels prior to 3.10.0-693.x
https://readykernel.com/
--
Best regards,
Konstantin Khorenko,
Virtuozzo Linux Kernel Team
On 09/05/2017 03:18 PM, Konstantin Khorenko wrote:
The commit is pushed to "branch-rh7-3.10.0
The commit is pushed to "branch-rh7-3.10.0-693.1.1.vz7.37.x-ovz" and will
appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-693.1.1.vz7.37.2
-->
commit 5ce3e1be78f85902e8606e77a1883248dbc5ea6e
Author: Konstantin Khorenko
Date: Tue Sep 5 15:24:34 2017 +0300
ve/autof
The commit is pushed to "branch-rh7-3.10.0-514.26.1.vz7.35.x-ovz" and will
appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-514.26.1.vz7.35.6
-->
commit e851cc10aa14e1ca311187fda9a3a53a5e3dee25
Author: Konstantin Khorenko
Date: Tue Sep 5 15:13:26 2017 +0300
ve/aut
Kirill Tkhai writes:
> When a FUSE process is making shrink, it must not wait
> on page writeback. Otherwise, it may meet a page,
> that is being writebacked by him, and the process will stall.
>
> So, our kernel does not wait writeback after commit a9707947010d
> "mm: vmscan: never wait on write
We have a problem on several our nodes with scsi EH. Imagine such an
order of execution of two threads:
CPU1 scsi_eh_scmd_add CPU2 scsi_host_queue_ready
/* shost->host_busy == 1 initialy */
if (shost->shost_state == SHOST_RECOVERY)
When a FUSE process is making shrink, it must not wait
on page writeback. Otherwise, it may meet a page,
that is being writebacked by him, and the process will stall.
So, our kernel does not wait writeback after commit a9707947010d
"mm: vmscan: never wait on writeback pages".
But in case of huge
10 matches
Mail list logo
