The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andi Kleen <andi@firstfloor.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Roland McGrath <roland@redhat.com>,
	akpm@linux-foundation.org, mm-commits@vger.kernel.org,
	npiggin@suse.de, drepper@redhat.com, oleg@tv-sign.ru,
	sebastien.dugue@bull.net, linux-kernel@vger.kernel.org
Subject: Re: [patch] change futex_wait() to hrtimers
Date: Mon, 12 Mar 2007 12:20:45 +0100	[thread overview]
Message-ID: <20070312112045.GC11864@one.firstfloor.org> (raw)
In-Reply-To: <20070312110417.GA12308@elte.hu>

> if HIGH_RES_TIMERS is disabled then that is what happens. But frankly, 

disabled? I would expect it (= more wakeups) when hrtimers are enabled.

> most futex waits are without timeouts - if an application cares about 
> micro-effects like that then you are much better off not using a 
> per-futex timeout anywa

That sounds like you're arguing for not using hrtimers here because
the applications shouldn't depend on precise timeouts here anyways?!? 

Anyways when you convert more kernel timeouts to hrtimers you should
probably add some kind of batching facility that can be globally
configured with a sysctl or similar. Then at least laptops (and possibly
servers) can opt for more power saving again. For the futexes alone
it probably won't matter too much agreed, but I see a trend to more hr.

I also liked the idea (stolen from another popular OS) that a application
can tell the OS how precise it wants its wakeups to be.

-Andi


  reply	other threads:[~2007-03-12 11:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200703110814.l2B8EaI1007615@shell0.pdx.osdl.net>
     [not found] ` <20070312011259.3834A1801C4@magilla.sf.frob.com>
2007-03-12  9:10   ` [patch] change futex_wait() to hrtimers Ingo Molnar
2007-03-12  9:16     ` Nick Piggin
2007-03-12 11:02       ` Ingo Molnar
2007-03-12 11:13         ` Nick Piggin
2007-03-12 11:19           ` Ingo Molnar
2007-03-12 11:29             ` Nick Piggin
2007-03-12 11:38               ` Ingo Molnar
2007-03-12 11:52                 ` Nick Piggin
2007-03-12 12:21                   ` Ingo Molnar
2007-03-12 12:36                     ` Nick Piggin
2007-03-12 11:19         ` Thomas Gleixner
2007-03-12 11:27     ` Andi Kleen
2007-03-12 11:00       ` Thomas Gleixner
2007-03-12 10:58         ` Andi Kleen
2007-03-12 11:04           ` Ingo Molnar
2007-03-12 11:20             ` Andi Kleen [this message]
2007-03-12 11:28               ` Ingo Molnar
2007-03-12 14:12           ` Theodore Tso
2007-03-12 14:22             ` Andi Kleen
2007-03-12 14:31             ` Ingo Molnar
2007-03-12 14:32             ` Nick Piggin
2007-03-15  0:03 linux

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=20070312112045.GC11864@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=akpm@linux-foundation.org \
    --cc=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mm-commits@vger.kernel.org \
    --cc=npiggin@suse.de \
    --cc=oleg@tv-sign.ru \
    --cc=roland@redhat.com \
    --cc=sebastien.dugue@bull.net \
    --cc=tglx@linutronix.de \
    /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