linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Christoph Lameter <cl@linux.com>
Cc: Tejun Heo <tj@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@suse.cz>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>, Shaohua Li <shli@fb.com>,
	linux-mm <linux-mm@kvack.org>
Subject: Re: [GIT PULL] workqueue fixes for v4.3-rc5
Date: Wed, 14 Oct 2015 12:10:29 -0700	[thread overview]
Message-ID: <CA+55aFzhzLZ6jeRqiHrguUG3oXMCxMzoQiLNvgE92a8NBJfksQ@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1510141358460.13663@east.gentwo.org>

On Wed, Oct 14, 2015 at 11:59 AM, Christoph Lameter <cl@linux.com> wrote:
> On Wed, 14 Oct 2015, Linus Torvalds wrote:
>
>> And "schedule_delayed_work()" uses WORK_CPU_UNBOUND.
>
> Uhhh. Someone changed that?

It always did.  This is from 2007:

int fastcall schedule_delayed_work(struct delayed_work *dwork,
                                        unsigned long delay)
{
        timer_stats_timer_set_start_info(&dwork->timer);
        return queue_delayed_work(keventd_wq, dwork, delay);
}
...
int fastcall queue_delayed_work(struct workqueue_struct *wq,
                        struct delayed_work *dwork, unsigned long delay)
{
        timer_stats_timer_set_start_info(&dwork->timer);
        if (delay == 0)
                return queue_work(wq, &dwork->work);

        return queue_delayed_work_on(-1, wq, dwork, delay);
}
...
int queue_delayed_work_on(int cpu, struct workqueue_struct *wq,
                        struct delayed_work *dwork, unsigned long delay)
{
....
                timer->function = delayed_work_timer_fn;

                if (unlikely(cpu >= 0))
                        add_timer_on(timer, cpu);
                else
                        add_timer(timer);
}
...
void delayed_work_timer_fn(unsigned long __data)
{
        int cpu = smp_processor_id();
        ...
        __queue_work(per_cpu_ptr(wq->cpu_wq, cpu), &dwork->work);
}


so notice how it always just used "add_timer()", and then queued it on
whatever cpu workqueue the timer ran on.

Now, 99.9% of the time, the timer is just added to the current CPU
queues, so yes, in practice it ended up running on the same CPU almost
all the time. There are exceptions (timers can get moved around, and
active timers end up staying on the CPU they were scheduled on when
they get updated, rather than get moved to the current cpu), but they
are hard to hit.

But the code clearly didn't do that "same CPU" intentionally, and just
going by naming of things I would also say that it was never implied.

                    Linus

--
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-10-14 19:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20151013214952.GB23106@mtj.duckdns.org>
2015-10-14 16:30 ` Linus Torvalds
2015-10-14 16:57   ` Tejun Heo
2015-10-14 17:36     ` Linus Torvalds
2015-10-14 17:57       ` Christoph Lameter
2015-10-14 18:37         ` Linus Torvalds
2015-10-14 18:58           ` Christoph Lameter
2015-10-14 19:01           ` Linus Torvalds
2015-10-14 19:02       ` Tejun Heo
2015-10-14 19:16         ` Linus Torvalds
2015-10-14 19:38           ` Tejun Heo
2015-10-14 20:10             ` Linus Torvalds
2015-10-14 20:24               ` Tejun Heo
2015-10-19  3:51                 ` Mike Galbraith
2015-10-16 19:51               ` [PATCH] vmstat_update: ensure work remains on the same core Chris Metcalf
2015-10-16 19:54                 ` Linus Torvalds
2015-10-14 18:03   ` [GIT PULL] workqueue fixes for v4.3-rc5 Christoph Lameter
2015-10-14 18:40     ` Linus Torvalds
2015-10-14 18:59       ` Christoph Lameter
2015-10-14 19:10         ` Linus Torvalds [this message]

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=CA+55aFzhzLZ6jeRqiHrguUG3oXMCxMzoQiLNvgE92a8NBJfksQ@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=jiangshanlai@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=shli@fb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox