From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754289AbZBDERb (ORCPT ); Tue, 3 Feb 2009 23:17:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751821AbZBDERV (ORCPT ); Tue, 3 Feb 2009 23:17:21 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:33934 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751358AbZBDERV (ORCPT ); Tue, 3 Feb 2009 23:17:21 -0500 Date: Tue, 3 Feb 2009 20:16:42 -0800 From: Andrew Morton To: Rusty Russell Cc: =?ISO-8859-1?Q?Fr=E9d=E9ric?= Weisbecker , mingo@elte.hu, linux-kernel@vger.kernel.org, oleg@redhat.com, travis@sgi.com, a.p.zijlstra@chello.nl, mm-commits@vger.kernel.org Subject: Re: + work_on_cpu-rewrite-it-to-create-a-kernel-thread-on-demand.patch added to -mm tree Message-Id: <20090203201642.057a07b9.akpm@linux-foundation.org> In-Reply-To: <200902041428.12059.rusty@rustcorp.com.au> References: <200902031058.n13AwOoK016719@imap1.linux-foundation.org> <20090203112529.26e6bf76.akpm@linux-foundation.org> <200902041428.12059.rusty@rustcorp.com.au> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.5; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 4 Feb 2009 14:28:11 +1030 Rusty Russell wrote: > On Wednesday 04 February 2009 05:55:29 Andrew Morton wrote: > > On Tue, 3 Feb 2009 17:58:13 +0100 > > Fr__d__ric Weisbecker wrote: > > > > > 2009/2/3 Ingo Molnar : > > > > > > > > * akpm@linux-foundation.org wrote: > > > > > > > >> ------------------------------------------------------ > > > >> Subject: work_on_cpu(): rewrite it to create a kernel thread on demand > > > >> From: Andrew Morton > > > >> > > > >> The various implemetnations and proposed implemetnations of work_on_cpu() > > > >> are vulnerable to various deadlocks because they all used queues of some > > > >> form. > > > >> > > > >> Unrelated pieces of kernel code thus gained dependencies wherein if one > > > >> work_on_cpu() caller holds a lock which some other work_on_cpu() callback > > > >> also takes, the kernel could rarely deadlock. > > > >> > > > >> Fix this by creating a short-lived kernel thread for each work_on_cpu() > > > >> invokation. > > > >> > > > >> This is not terribly fast, but the only current caller of work_on_cpu() is > > > >> pci_call_probe(). > > > > > > > > hm, it's quite ugly as well > > > > No it isn't. > > > > It's no less ugly than the current code. > > > > It's less buggy than the current code. > > Whatever, I like your version. Careful, or you'll own it ;) > Tho making it a series of 5 and exposing rdmsr_on_cpu/wrmsr_on_cpu for other > uses would be even better. These: int rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32 *h); int wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h); int rdmsr_safe_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32 *h); int wrmsr_safe_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h); already exist. I don't think anything else needs to be done here?