WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [Patch] support of lock profiling in Xen

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [Patch] support of lock profiling in Xen
From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Date: Thu, 08 Oct 2009 10:27:38 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 08 Oct 2009 01:28:02 -0700
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1254990524; x=1286526524; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Juergen=20Gross=20<juergen.gross@xxxxxxxxxxxxxx> |Subject:=20Re:=20[Xen-devel]=20[Patch]=20support=20of=20 lock=20profiling=20in=20Xen|Date:=20Thu,=2008=20Oct=20200 9=2010:27:38=20+0200|Message-ID:=20<4ACDA27A.80603@xxxxxx itsu.com>|To:=20Keir=20Fraser=20<keir.fraser@xxxxxxxxxxxx m>|CC:=20"xen-devel@xxxxxxxxxxxxxxxxxxx"=20<xen-devel@lis ts.xensource.com>|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<C6F35E 30.16D85%keir.fraser@xxxxxxxxxxxxx>|References:=20<C6F35E 30.16D85%keir.fraser@xxxxxxxxxxxxx>; bh=qyu7Qd5bkecFQHh0/ODzEzOBSbVpnaZ0WNJ1o5Je+Tg=; b=rde3PA7pFBdPjOjy+9FqL4lt8LgjTrmalGsQ/FHSmJDs7iDhgxFZeGWT dk91Fulb3w1/ZwnYvmHi7N1KYn4bNikdqIJyawVbC4mzacVV4Yh0gzfcg s9lQnhwlg/A0/lC1ZR0sP330+jCH+eVg3iOTwTdHHeHfDIQ/Q/NWlxBNr gTsMFAHtnepVIQd9lTk4JusncQ+wzIEa5ERUZR+xhY3j8U4lbsn8Gcs3A zhc0SGmEZ+F1CgFCXPptP482W9z2R;
Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=s3U4DVXKQYZwqBRYLtXa08IBTRL7uHMIJ5LY3Q/8ANa//HG8aiRufzv+ I0gW1TnW9k1YwQQLsC2Zq8LMWoloWyOZonK9IynJAAdgHe2ohyAJDEizx /aZ0qQfdG7xhycwVNQ5NDidlQH6rFI36bljYUGepo76xz7mdksyGeg6ly DQcMxHLO6tD1NcTUOSza3W8zla5eFUXO8LZ1NSKy0jaGudgfbjLMyRI0F CHGd/qPRyMWYSIlkdX2SeUPWGtIJN;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C6F35E30.16D85%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Fujitsu Technology Solutions
References: <C6F35E30.16D85%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707)
Keir Fraser wrote:
> On 08/10/2009 08:48, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx> wrote:
> 
>> I'm not completely satisfied with the solution for the dynamically 
>> initialized
>> locks, but I had no better idea in the first run.
>> Another enhancement would be to expand the profiling to rw-locks as well, but
>> this would have required a rewrite of the lock routines using try_lock like
>> for spinlocks. I could do this if the lock profiling is accepted.
>>
>> Comments welcome :-)
> 
> The method of chaining and initialising the info is kind of icky. Requiring
> users to unchain dynamic locks is just asking for this support to be
> perpetually broken, or be used only for static locks.
> 
> How about defining new initialisers DEFINE_NAMED_SPINLOCK() and
> named_spinlock_init(). This would indicate you consider a lock important
> enough to name (and hence profile) and also categorise dynamically-allocated
> locks, causing their stats to be aggregated (after all, lock optimisations
> will have aggregate effect across all locks of that category).
> 
> If lock profiling is compiled in, have a static array of lock-profile
> descriptors (keeps things simple - could make it a growable array, or
> something). On lock init, walk the array looking for that name. If found,
> write the entry index into a new field in the spinlock struct. If not found,
> allocate next entry in lock-profile array, init it, and write its index into
> the spinlock struct.

Don't you think a solution like for performance counters would be better then?
The index would be in a header file and the sums could be held per-cpu to
avoid races.
It would even be possible to define lock arrays if summing up all data for
e.g. domain specific locks is not desired.

> 
> On lock operations, if the index field in the spinlock is non-zero, update
> stats in the associated profile structure. Regarding races from locks
> aliasing to the same profile structure -- either assume that doesn't matter
> much, or perhaps update fields with atomic ops.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 636 47950
Fujitsu Technolgy Solutions               e-mail: juergen.gross@xxxxxxxxxxxxxx
Otto-Hahn-Ring 6                        Internet: ts.fujitsu.com
D-81739 Muenchen                 Company details: ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel