[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1287062664.29097.195.camel@twins>
Date: Thu, 14 Oct 2010 15:24:24 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: balbir@...ux.vnet.ibm.com
Cc: Bharata B Rao <bharata@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org,
Dhaval Giani <dhaval.giani@...il.com>,
Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
Srivatsa Vaddagiri <vatsa@...ibm.com>,
Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
Ingo Molnar <mingo@...e.hu>,
Pavel Emelyanov <xemul@...nvz.org>,
Herbert Poetzl <herbert@...hfloor.at>,
Avi Kivity <avi@...hat.com>,
Chris Friesen <cfriesen@...tel.com>,
Paul Menage <menage@...gle.com>,
Mike Waychison <mikew@...gle.com>,
Paul Turner <pjt@...gle.com>, Nikhil Rao <ncrao@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v3 1/7] sched: introduce primitives to account for CFS
bandwidth tracking
On Thu, 2010-10-14 at 18:08 +0530, Balbir Singh wrote:
> > >
> > > hrtimer_start_expires(period_timer, HRTIMER_MODE_ABS_PINNED) if we
> > > don't care about wakeup_softirq, is there a reason we prefer to keep
> > > wakeup as 0?
> >
> > You cannot do wakeups while holding the rq->lock, can you? :-)
> >
>
> :-) Yes, given that we wakeup softirq only for the current CPU. There
> is scope for some code reuse anyway, I'll see if I can send a patch.
Well, both Thomas and I would like hrtimer_start() and friends to return
-ETIME in this case. But that means changing all callers to cope with
that, and sweeping the tree to make that happen is like lots of work.
--
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