Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268259AbUIPRBg (ORCPT ); Thu, 16 Sep 2004 13:01:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268317AbUIPQrY (ORCPT ); Thu, 16 Sep 2004 12:47:24 -0400 Received: from dragnfire.mtl.istop.com ([66.11.160.179]:38356 "EHLO dsl.commfireservices.com") by vger.kernel.org with ESMTP id S268185AbUIPQoW (ORCPT ); Thu, 16 Sep 2004 12:44:22 -0400 Date: Thu, 16 Sep 2004 12:44:23 +0000 (UTC) From: Zwane Mwaikambo To: Ingo Molnar Cc: Andi Kleen , Andrew Morton , linux-kernel@vger.kernel.org, wli@holomorphy.com Subject: Re: [PATCH] remove LOCK_SECTION from x86_64 spin_lock asm In-Reply-To: <20040916062759.GA10527@elte.hu> Message-ID: References: <20040915144523.0fec2070.akpm@osdl.org> <20040916061359.GA12915@wotan.suse.de> <20040916062759.GA10527@elte.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1008 Lines: 29 On Thu, 16 Sep 2004, Ingo Molnar wrote: > the ebp trick is nice, but forcing a formal stack frame for every > function has global performance implications. Couldnt we define some > sort of current-> field [or current_thread_info() field] that the > spinlock code could set and clear, which field would be listened to by > profile_pc(), so that the time spent spinning would be attributed to the > callee? Something like: I think the generic route is nice but wouldn't this break with the following. taskA: spin_lock(lockA); // contended int1: spin_lock(lockB) I was thinking along the likes of a per_cpu real_pc, but realised it falls prey to the same problem as above... Unless we have irq threads, then of course your solution works. Zwane - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/