[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1239302075.4557.4225.camel@laptop>
Date: Thu, 09 Apr 2009 20:34:35 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Jeremy Fitzhardinge <jeremy@...p.org>
Cc: Heiko Carstens <heiko.carstens@...ibm.com>,
Ingo Molnar <mingo@...e.hu>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Christian Borntraeger <borntraeger@...ibm.com>,
linux-kernel@...r.kernel.org, Avi Kivity <avi@...hat.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] mutex: have non-spinning mutexes on s390 by default
On Thu, 2009-04-09 at 10:50 -0700, Jeremy Fitzhardinge wrote:
> Peter Zijlstra wrote:
> > On Thu, 2009-04-09 at 18:53 +0200, Peter Zijlstra wrote:
> >
> >
> >> I was looking at how an monitor-wait could be used here, but that
> >> appears non-trivial, there's two variables we're watching, lock->owner
> >> and rq->curr, either could change.
> >>
> >> Reducing that to 1 seems an interesting problem :-)
> >>
> >
> > How about something like this?
> >
> > Does it make sense to implement an monitor-wait spinlock for the virt
> > case as well? Avi, Jeremy?
> >
>
> Last time I tried to put mwait in a spinlock, Arjan (or HPA?) said that
> mwait takes approx a week and a half to wake up, and that it was really
> only useful for idle power savings.
Yeah, sad that.
> Has that changed?
Nothing much, I was thinking perhaps it would make sense for the virt
case, but if its not properly virtualized then its pretty useless
indeed.
monitor-wait is basically a hardware/hv futex like thing, so I thought
it might help -- spinning in a guest is pretty painful.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists