All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <aarcange@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>,
	"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
	"Rafael J. Wysocki" <rjw@suse.com>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jiri Slaby <jirislaby@gmail.com>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] thp: reduce khugepaged freezing latency
Date: Wed, 9 Nov 2011 18:33:08 +0100	[thread overview]
Message-ID: <20111109173308.GK5075@redhat.com> (raw)
In-Reply-To: <20111109170657.GE1260@google.com>

On Wed, Nov 09, 2011 at 09:06:57AM -0800, Tejun Heo wrote:
> Ah, crap, still waking up.  Sorry about that.  So, yes, there's a race
> condition above.  You need to set TASK_INTERRUPTIBLE before testing
> freezing and use schedule_timeout() instead of

Yep that's the race I was thinking about. I see the wakeup in the
no-signal case avoids the race in wait_even_freezable_timeout so that
is ok but it'd race if I were just to add try_to_freeze before calling
schedule_timeout_interruptible.

> schedule_timeout_interruptible().  Was getting confused with
> prepare_to_wait().  That said, why not use prepare_to_wait() instead?

Because I don't need to wait on a waitqueue there. A THP failure
occurred, that caused some CPU overload and it's usually happening at
time of heavy VM stress, so I don't want to retry and cause more CPU
load from khugepaged until after some time even if more wakeups come
by. khugepaged is a very low cost background op, so it shouldn't cause
unnecessary CPU usage at times of VM pressure, waiting a better time
later is better.

WARNING: multiple messages have this Message-ID (diff)
From: Andrea Arcangeli <aarcange@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>,
	"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
	"Rafael J. Wysocki" <rjw@suse.com>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jiri Slaby <jirislaby@gmail.com>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] thp: reduce khugepaged freezing latency
Date: Wed, 9 Nov 2011 18:33:08 +0100	[thread overview]
Message-ID: <20111109173308.GK5075@redhat.com> (raw)
In-Reply-To: <20111109170657.GE1260@google.com>

On Wed, Nov 09, 2011 at 09:06:57AM -0800, Tejun Heo wrote:
> Ah, crap, still waking up.  Sorry about that.  So, yes, there's a race
> condition above.  You need to set TASK_INTERRUPTIBLE before testing
> freezing and use schedule_timeout() instead of

Yep that's the race I was thinking about. I see the wakeup in the
no-signal case avoids the race in wait_even_freezable_timeout so that
is ok but it'd race if I were just to add try_to_freeze before calling
schedule_timeout_interruptible.

> schedule_timeout_interruptible().  Was getting confused with
> prepare_to_wait().  That said, why not use prepare_to_wait() instead?

Because I don't need to wait on a waitqueue there. A THP failure
occurred, that caused some CPU overload and it's usually happening at
time of heavy VM stress, so I don't want to retry and cause more CPU
load from khugepaged until after some time even if more wakeups come
by. khugepaged is a very low cost background op, so it shouldn't cause
unnecessary CPU usage at times of VM pressure, waiting a better time
later is better.

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-11-09 17:33 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-08  8:33 khugepaged doesn't want to freeze Jiri Slaby
2011-11-08  8:33 ` Jiri Slaby
2011-11-08 15:29 ` Andrea Arcangeli
2011-11-08 15:29   ` Andrea Arcangeli
2011-11-08 15:29   ` [PATCH] thp: reduce khugepaged freezing latency Andrea Arcangeli
2011-11-08 15:29     ` Andrea Arcangeli
2011-11-08 20:01     ` Srivatsa S. Bhat
2011-11-08 20:01       ` Srivatsa S. Bhat
2011-11-09  0:01       ` Andrea Arcangeli
2011-11-09  0:01         ` Andrea Arcangeli
2011-11-09  9:03         ` Srivatsa S. Bhat
2011-11-09  9:03           ` Srivatsa S. Bhat
2011-11-09 12:45       ` Srivatsa S. Bhat
2011-11-09 12:45         ` Srivatsa S. Bhat
2011-11-09 15:53         ` Tejun Heo
2011-11-09 15:53           ` Tejun Heo
2011-11-09 16:20           ` Srivatsa S. Bhat
2011-11-09 16:20             ` Srivatsa S. Bhat
2011-11-09 16:52           ` Andrea Arcangeli
2011-11-09 16:52             ` Andrea Arcangeli
2011-11-09 16:59             ` Tejun Heo
2011-11-09 16:59               ` Tejun Heo
2011-11-09 17:02               ` Tejun Heo
2011-11-09 17:02                 ` Tejun Heo
2011-11-09 17:29                 ` Andrea Arcangeli
2011-11-09 17:29                   ` Andrea Arcangeli
2011-11-09 18:09                   ` Tejun Heo
2011-11-09 18:09                     ` Tejun Heo
2011-11-09 18:19                     ` Andrea Arcangeli
2011-11-09 18:19                       ` Andrea Arcangeli
2011-11-09 18:34                       ` Tejun Heo
2011-11-09 18:34                         ` Tejun Heo
2011-11-09 19:40                         ` Andrea Arcangeli
2011-11-09 19:40                           ` Andrea Arcangeli
2011-11-11 12:20                           ` Jiri Slaby
2011-11-11 12:20                             ` Jiri Slaby
2011-11-09 17:06               ` Tejun Heo
2011-11-09 17:06                 ` Tejun Heo
2011-11-09 17:33                 ` Andrea Arcangeli [this message]
2011-11-09 17:33                   ` Andrea Arcangeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111109173308.GK5075@redhat.com \
    --to=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=jirislaby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=rjw@suse.com \
    --cc=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.