All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Ingo Molnar <mingo@elte.hu>, Jens Axboe <jens.axboe@oracle.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Christian Borntraeger <cborntra@de.ibm.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Arjan van de Ven <arjan@infradead.org>
Subject: Re: [PATCH RFC 1/3] Add a trigger API for efficient non-blocking waiting
Date: Tue, 19 Aug 2008 23:21:08 -0700	[thread overview]
Message-ID: <20080819232108.c03660fa.akpm@linux-foundation.org> (raw)
In-Reply-To: <48A70185.2020600@goop.org>

On Sat, 16 Aug 2008 09:34:13 -0700 Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> There are various places in the kernel which wish to wait for a
> condition to come true while in a non-blocking context.  Existing
> examples of this are stop_machine() and smp_call_function_mask().
> (No doubt there are other instances of this pattern in the tree.)
> 
> Thus far, the only way to achieve this is by spinning with a
> cpu_relax() loop.  This is fine if the condition becomes true very
> quickly, but it is not ideal:
> 
>  - There's little opportunity to put the CPUs into a low-power state.
>    cpu_relax() may do this to some extent, but if the wait is
>    relatively long, then we can probably do better.

If this change saves a significant amount of power then we should fix
the offending callsites.

>  - In a virtual environment, spinning virtual CPUs just waste CPU
>    resources, and may steal CPU time from vCPUs which need it to make
>    progress.  The trigger API allows the vCPUs to give up their CPU
>    entirely.  The s390 people observed a problem with stop_machine
>    taking a very long time (seconds) when there are more vcpus than
>    available cpus.

If this change saves a significant amount of virtual-cpu-time then we
should fix the offending callsites.


Tell me I'm wrong...

  parent reply	other threads:[~2008-08-20  6:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-16 16:34 [PATCH RFC 1/3] Add a trigger API for efficient non-blocking waiting Jeremy Fitzhardinge
2008-08-16 17:47 ` Arjan van de Ven
2008-08-17 23:02 ` Randy Dunlap
2008-08-20  6:21 ` Andrew Morton [this message]
2008-08-20 18:42   ` Jeremy Fitzhardinge
2008-08-20 19:25     ` Andrew Morton
2008-08-20 20:14       ` Jeremy Fitzhardinge
2008-08-25  0:53       ` Rusty Russell
2008-08-28 12:27 ` Christian Borntraeger

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=20080819232108.c03660fa.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=arjan@infradead.org \
    --cc=cborntra@de.ibm.com \
    --cc=jens.axboe@oracle.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    /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.