From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11165 invoked by alias); 5 Aug 2005 16:25:12 -0000 Mailing-List: contact systemtap-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sources.redhat.com Received: (qmail 11094 invoked by uid 22791); 5 Aug 2005 16:25:07 -0000 Date: Fri, 05 Aug 2005 16:25:00 -0000 From: Mathieu Desnoyers To: Andi Kleen Cc: systemtap@sources.redhat.com Subject: Re: Hitachi djprobe mechanism Message-ID: <20050805162258.GA24930@Krystal> References: <44BDAFB888F59F408FAE3CC35AB4704101E98AF5@orsmsx409> <20050801203109.43B55180EC3@magilla.sf.frob.com> <20050804002656.GA17537@Krystal> <20050804100139.GO8266@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <20050804100139.GO8266@wotan.suse.de> X-Editor: vi X-Info: http://krystal.dyndns.org:8080 X-Operating-System: Linux/2.4.30-grsec (i686) X-Uptime: 12:15:09 up 49 days, 10:26, 3 users, load average: 0.19, 0.33, 0.33 User-Agent: Mutt/1.5.9i X-SW-Source: 2005-q3/txt/msg00291.txt.bz2 * Andi Kleen (ak@suse.de) wrote: > On Wed, Aug 03, 2005 at 08:26:56PM -0400, Mathieu Desnoyers wrote: > > * Roland McGrath (roland@redhat.com) wrote: > > > It's OK for probe insertion to be slow. So why not use RCU to synchronize > > > other processors? > > > > > > > No, > > > > The reason is we have no control on preemption disabling around the concerned > > area. > > Task list walking and checking of the IP of blocked processes can avoid that > as earlier discussed. But it doesn't solve all problems with short instructions. > IPI is the most practical one. > > No practical solution has been elaborated for a fully preemptible kernel. Even walking on the talk list checking for potential iret pointers is not a good idea: If you have a stopped process that has its instruction pointer exactly in the wrong area, then you may wait forever. Per cpu workqueue to make sure none is still in interrupt context would, I think, do the same as a non maskable IPI but without the busy looping. Mathieu OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68