On 12/18/17 12:41 AM, Michal Hocko wrote:
On Sat 16-12-17 23:09:25, Kirill A. Shutemov wrote:
On Sat, Dec 16, 2017 at 12:45:25PM +0100, Michal Hocko wrote:
On Sat 16-12-17 04:04:10, Yang Shi wrote:
[...]
Shall we add "cond_resched()" in unmap_vmas(), i.e for every 100 vmas? It
may improve t
On Mon, Dec 18, 2017 at 09:41:19AM +0100, Michal Hocko wrote:
> On Sat 16-12-17 23:09:25, Kirill A. Shutemov wrote:
> > On Sat, Dec 16, 2017 at 12:45:25PM +0100, Michal Hocko wrote:
> > > On Sat 16-12-17 04:04:10, Yang Shi wrote:
> [...]
> > > > Shall we add "cond_resched()" in unmap_vmas(), i.e fo
On Sat 16-12-17 23:09:25, Kirill A. Shutemov wrote:
> On Sat, Dec 16, 2017 at 12:45:25PM +0100, Michal Hocko wrote:
> > On Sat 16-12-17 04:04:10, Yang Shi wrote:
[...]
> > > Shall we add "cond_resched()" in unmap_vmas(), i.e for every 100 vmas? It
> > > may improve the responsiveness a little bit f
On 12/16/17 12:09 PM, Kirill A. Shutemov wrote:
On Sat, Dec 16, 2017 at 12:45:25PM +0100, Michal Hocko wrote:
On Sat 16-12-17 04:04:10, Yang Shi wrote:
Hi Kirill & Michal,
Since both of you raised the same question about who holds the semaphore for
that long time, I just reply here to both o
On Sat, Dec 16, 2017 at 12:45:25PM +0100, Michal Hocko wrote:
> On Sat 16-12-17 04:04:10, Yang Shi wrote:
> > Hi Kirill & Michal,
> >
> > Since both of you raised the same question about who holds the semaphore for
> > that long time, I just reply here to both of you.
> >
> > The backtrace shows
On Sat 16-12-17 04:04:10, Yang Shi wrote:
> Hi Kirill & Michal,
>
> Since both of you raised the same question about who holds the semaphore for
> that long time, I just reply here to both of you.
>
> The backtrace shows vm-scalability is running with 300G memory and it is
> doing munmap as below
Hi Kirill & Michal,
Since both of you raised the same question about who holds the semaphore
for that long time, I just reply here to both of you.
The backtrace shows vm-scalability is running with 300G memory and it is
doing munmap as below:
[188995.241865] CPU: 15 PID: 8063 Comm: usemem T
On Fri 15-12-17 03:53:23, Yang Shi wrote:
> In the current design, khugepaged need acquire mmap_sem before scanning
> mm, but in some corner case, khugepaged may scan the current running
> process which might be modifying memory mapping, so khugepaged might
> block in uninterruptible state. But, th
On Fri, Dec 15, 2017 at 10:04:27AM +0530, Anshuman Khandual wrote:
> On 12/15/2017 01:23 AM, Yang Shi wrote:
> > In the current design, khugepaged need acquire mmap_sem before scanning
> > mm, but in some corner case, khugepaged may scan the current running
> > process which might be modifying memo
On 12/15/2017 01:23 AM, Yang Shi wrote:
> In the current design, khugepaged need acquire mmap_sem before scanning
> mm, but in some corner case, khugepaged may scan the current running
> process which might be modifying memory mapping, so khugepaged might
> block in uninterruptible state. But, the
In the current design, khugepaged need acquire mmap_sem before scanning
mm, but in some corner case, khugepaged may scan the current running
process which might be modifying memory mapping, so khugepaged might
block in uninterruptible state. But, the process might hold the mmap_sem
for long time wh
11 matches
Mail list logo