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
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
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
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
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
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
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
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
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, 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
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
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
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
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,
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,
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
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
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
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
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
22 matches
Mail list logo
