From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760115AbZBXToZ (ORCPT ); Tue, 24 Feb 2009 14:44:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758035AbZBXTnx (ORCPT ); Tue, 24 Feb 2009 14:43:53 -0500 Received: from e31.co.us.ibm.com ([32.97.110.149]:43910 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754501AbZBXTnw (ORCPT ); Tue, 24 Feb 2009 14:43:52 -0500 Date: Tue, 24 Feb 2009 13:43:29 -0600 From: "Serge E. Hallyn" To: Dave Hansen Cc: containers , Ingo Molnar , Alexey Dobriyan , "linux-kernel@vger.kernel.org" Subject: Re: [RFC][PATCH 3/5] check files for checkpointability Message-ID: <20090224194329.GC24007@us.ibm.com> References: <20090219182007.B4B47C1F@kernel> <20090219182009.1A3E8860@kernel> <20090223234911.GB2590@us.ibm.com> <1235435430.26788.212.camel@nimitz> <20090224011037.GB4797@us.ibm.com> <1235438459.26788.222.camel@nimitz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1235438459.26788.222.camel@nimitz> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Dave Hansen (dave@linux.vnet.ibm.com): > On Mon, 2009-02-23 at 19:10 -0600, Serge E. Hallyn wrote: > > > This allows us to tell where and when we went wrong. Take a process > > > that's been running for a month. After 5 days it did something random > > > to keep it from being checkpointed. You're going to have forgotten all > > > about it 25 days later. This gives us an opportunity to spit into dmesg > > > or just plain log it. It also gives the app some ability to reflect and > > > see what its uncheckpointable attributes are. > > > > Hmm. In that case, rather than refuse checkpoint, I prefer that we make > > this a footnote in the /proc/$$/checkpointable output. > > Yeah, that's cool. If we were smart, we'd also get hooked into some of > the ftrace output so that we have a real chance of logging these things > and being able to go look at something about them down the line. How exactly woudl that work? Would that work as a *replacement* for filling up the logs as I was recommending? If so I'm all for it... -serge