From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261389AbULTCKj (ORCPT ); Sun, 19 Dec 2004 21:10:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261390AbULTCKi (ORCPT ); Sun, 19 Dec 2004 21:10:38 -0500 Received: from smtp105.mail.sc5.yahoo.com ([66.163.169.225]:46470 "HELO smtp105.mail.sc5.yahoo.com") by vger.kernel.org with SMTP id S261389AbULTB43 (ORCPT ); Sun, 19 Dec 2004 20:56:29 -0500 Subject: Re: [PATCH] Remove RCU abuse in cpu_idle() From: Nick Piggin To: Zwane Mwaikambo Cc: Nish Aravamudan , "Paul E. McKenney" , Andrew Morton , Stephen Rothwell , Linux Kernel , Dipankar Sarma , Li Shaohua , Len Brown In-Reply-To: References: <20041205004557.GA2028@us.ibm.com> <20041205232007.7edc4a78.akpm@osdl.org> <20041206160405.GB1271@us.ibm.com> <20041206192243.GC1435@us.ibm.com> <29495f1d04121818403f949fdd@mail.gmail.com> <1103505344.5093.4.camel@npiggin-nld.site> Content-Type: text/plain Date: Mon, 20 Dec 2004 12:56:24 +1100 Message-Id: <1103507784.5093.9.camel@npiggin-nld.site> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2004-12-19 at 18:44 -0700, Zwane Mwaikambo wrote: > On Mon, 20 Dec 2004, Nick Piggin wrote: > > > This thread can possibly be stalled forever if there is a CPU hog > > running, right? > > Yep. > > > In which case, you will want to use ssleep rather than a busy loop. > > Well ssleep essentially does the same thing as the schedule_timeout. > Yes - so long as you set ->state when using schedule_timeout ;) > > Another alternative may be to use more complex logic to detect that a > > CPU is not in the idle loop at all. In that case, a simple cpu_relax > > type spin loop should be OK, because the synchronisation would be > > achieved very quickly. > > I considered checking whether the cpu is in the idle thread or not but > wouldn't that require locking runqueues? Something like; > > pm_idle = new_value; > wmb(); > busy_map = cpu_online_map; > for_each_online_cpu(cpu) { > runqueue_t *rq = cpu_rq(cpu); > spin_lock_irq(&rq->lock); > if (rq->curr != rq->idle) > cpu_clear(cpu, busy_map); > spin_unlock_irq(&rq->lock); > } > > cpu_idle_map = busy_map; > wmb(); > > while (!cpus_empty(cpu_idle_map)) { > cpus_and(cpu_idle_map, cpu_idle_map, cpu_online_map); > ssleep(1); > } > > Hmm then again, i think we could get away with doing an unlocked compare > on the rq->curr and rq->idle since we've written back pm_idle and reading > a stale rq->curr which isn't equal to rq->idle means that the remote > processor should also have the new pm_idle. I'm still not convinced that > it deserves this much complexity, this is a rarely carried out operation > and usually at boottime or shutdown. > Hmm, yeah it is fairly complex, now that you've expanded on my handwaving! I think you are right about not requiring locking, so long as you have the appropriate memory barriers in place... but it's probably not worth the effort, as you say. Nick