From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH 3/7] xen: rework locking for dump of scheduler info (debug-key r) Date: Tue, 17 Mar 2015 11:32:02 +0000 Message-ID: <550810B2.4070801@eu.citrix.com> References: <20150316165642.10279.86684.stgit@Solace.station> <20150316170509.10279.79362.stgit@Solace.station> <55081607020000780006AAAE@mail.emea.novell.com> <55080A71.1070705@eu.citrix.com> <55081D29020000780006AB3C@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55081D29020000780006AB3C@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Keir Fraser , Dario Faggioli , Meng Xu , Xen-devel List-Id: xen-devel@lists.xenproject.org On 03/17/2015 11:25 AM, Jan Beulich wrote: >>>> On 17.03.15 at 12:05, wrote: >> On 03/17/2015 10:54 AM, Jan Beulich wrote: >>> Finally, as said in different contexts earlier, I think unconditionally >>> acquiring locks in dumping routines isn't the best practice. At least >>> in non-debug builds I think these should be try-locks only, skipping >>> the dumping when a lock is busy. >> >> You mean so that we don't block the console if there turns out to be a >> deadlock? > > For example. And also to not unduly get in the way of an otherwise > extremely busy system. I don't understand this last argument. If you're using the debug keys, you want to know about the state of the system. I would much rather my system ran 25% slower for the 5 seconds the debug key was dumping information, and have a complete snapshot of the system, than for it to only run 10% slower and to have half the information missing. The upshot of missing information would likely be that I have to press the debug key 3-4 times in a row, meaning I'd be running 10% slower for 20 seconds rather than 25% slower for 5 seconds. And in any case, the effect of being able to *successfully* grab the private lock is going to have a much larger impact on the system. All in all, I don't think the performance of the debug keys should be a major concern. The only thing I'd be worried about is making the system as diagnosable as possible if things have already gone pear-shaped (e.g., if there's a deadlock). > Yes, that might be a possible compromise. I could also imagine > another debug key allowing to alter the behavior, i.e. for when > one absolutely wants the information and doesn't care about > the state of the system. Possible, but it seems like a lot of complication for what it buys you. -George