linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Christoph Lameter <cl@linux.com>,
	Linaro Kernel Mailman List <linaro-kernel@lists.linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	vinmenon@codeaurora.org, shashim@codeaurora.org,
	Michal Hocko <mhocko@suse.cz>, Mel Gorman <mgorman@suse.de>,
	dave@stgolabs.net, Konstantin Khlebnikov <koct9i@gmail.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC] vmstat: Avoid waking up idle-cpu to service shepherd work
Date: Mon, 30 Mar 2015 17:32:16 +0530	[thread overview]
Message-ID: <CAKohpon2GSpk+6pNuHEsDC55hHtowwfGJivPM0Gh0wt1A2cd-w@mail.gmail.com> (raw)
In-Reply-To: <20150329102440.GC32047@worktop.ger.corp.intel.com>

On 29 March 2015 at 15:54, Peter Zijlstra <peterz@infradead.org> wrote:
> On Sat, Mar 28, 2015 at 02:44:57PM +0100, Peter Zijlstra wrote:
>> > Now there are few issues I see here (Sorry if they are all imaginary):
>> > - In case a timer re-arms itself from its handler and is migrated from CPU A to B, what
>> >   happens if the re-armed timer fires before the first handler finishes ? i.e. timer->fn()
>> >   hasn't finished running on CPU A and it has fired again on CPU B. Wouldn't this expose
>> >   us to a lot of other problems? It wouldn't be serialized to itself anymore ?
>>
>> What I said above.
>
> What I didn't say, but had thought of is that __run_timer() should skip
> any timer that has RUNNING set -- for obvious reasons :-)

Below is copied from your first reply, and so you probably already
said that ? :)

> Also, once you have tbase_running, we can take base->running_timer out
> altogether.

I wanted to clarify if I understood it correctly..

Are you saying that:

Case 1.) if we find tbase_running on cpuY (because it was rearmed
from its handler on cpuX and has got migrated to cpuY), then we should drop the
timer from the list without calling its handler (as that is already
running in parallel) ?

Or

Case 2.) we keep retrying for it, until the time the other handler finishes?


I have few queries for both the cases.

Case 1.) Will that be fair to the timer user as the timer may get lost
completely.
If we skip the timer on cpuY here, it wouldn't be enqueued again and
so will be lost.

Case 2.) We kept waiting for the first handler to finish ..
- cpuY may waste some cycles as it kept waiting for handler to finish on cpuX ..
- We may need to perform base unlock/lock on cpuY, so that cpuX can take cpuY's
lock to reset tbase_running. And that might be racy, not sure.

--
viresh

--
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>

  reply	other threads:[~2015-03-30 12:02 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-26  5:39 Viresh Kumar
2015-03-26 20:18 ` Andrew Morton
2015-03-27  4:49   ` Viresh Kumar
2015-03-27  9:16     ` Peter Zijlstra
2015-03-27  9:30       ` Peter Zijlstra
2015-03-27 11:11         ` Christoph Lameter
2015-03-27 12:02           ` Peter Zijlstra
2015-03-27 19:45             ` Christoph Lameter
2015-03-28  4:28             ` Viresh Kumar
2015-03-28 11:41               ` Peter Zijlstra
2015-03-28  4:18         ` Viresh Kumar
2015-03-28  9:53           ` Peter Zijlstra
2015-03-28 11:57             ` viresh kumar
2015-03-28 12:04               ` Viresh Kumar
2015-03-28 13:44               ` Peter Zijlstra
2015-03-29 10:24                 ` Peter Zijlstra
2015-03-30 12:02                   ` Viresh Kumar [this message]
2015-03-30 12:47                     ` Peter Zijlstra
2015-03-30 13:14                       ` Viresh Kumar
2015-03-30 13:59                         ` Peter Zijlstra
2015-03-30 16:17                           ` Viresh Kumar
2015-03-30 16:25                             ` Peter Zijlstra
2015-03-29 12:01                 ` Viresh Kumar
2015-03-29 17:24                   ` Peter Zijlstra
2015-03-30 15:08             ` Michal Hocko
2015-03-30 15:14               ` Peter Zijlstra
2015-03-30 15:42               ` Christoph Lameter
2015-03-27 14:19 ` Michal Hocko
2015-03-28  4:34   ` Viresh Kumar

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=CAKohpon2GSpk+6pNuHEsDC55hHtowwfGJivPM0Gh0wt1A2cd-w@mail.gmail.com \
    --to=viresh.kumar@linaro.org \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=dave@stgolabs.net \
    --cc=hannes@cmpxchg.org \
    --cc=koct9i@gmail.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.cz \
    --cc=peterz@infradead.org \
    --cc=shashim@codeaurora.org \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=vinmenon@codeaurora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox