From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: [concept & "good taste" review] persistent store Date: Tue, 21 Dec 2010 08:42:59 +0100 Message-ID: <20101221074259.GB32278@liondog.tnic> References: <4D0BEE1F.7020008@zytor.com> <20101219091752.GA16150@liondog.tnic> <1292813234.8743.66.camel@yhuang-dev> <1292892494.8743.76.camel@yhuang-dev> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Received: from mail.skyhub.de ([78.46.96.112]:34283 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753726Ab0LUHnE (ORCPT ); Tue, 21 Dec 2010 02:43:04 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Tony Luck Cc: Huang Ying , Linus Torvalds , "H. Peter Anvin" , "linux-kernel@vger.kernel.org" , "linux-arch@vger.kernel.org" , "tglx@linutronix.de" , "mingo@elte.hu" , "greg@kroah.com" , "akpm@linux-foundation.org" , David Miller , Alan Cox , Jim Keniston , Kyungmin Park , Geert Uytterhoeven On Mon, Dec 20, 2010 at 09:13:33PM -0800, Tony Luck wrote: > On Mon, Dec 20, 2010 at 4:48 PM, Huang Ying wrote: > > If persistent storage driver (such as ERST) implements kmsg_dumper by > > themselves, that should be easier to use multiple records for one > > message dumping request. > > Or I can build it into the fs/pstore layer. If the record size looks too > small[*], loop writing multiple records (starting with the tail of the buffer, > so that if the persistent store fills up, we are sure to have the stack > back trace and register dump). Wait a second, isn't this loop writing actually what we want?! I mean, if the pstore is big enough to contain, say the last ca. 50 or so oops messages (this size should suffice even for OOMkill oopses), we do make sure that we always have the last set of oopses belonging together and thus if we panic, we have also the relevant ones. [ IIRC, each ERST record can contain roughly 8K, and we want 50 of those so having a 1M flash on the platform isn't science fiction anymore, no? ] By loop writing it, we also make sure we overwrite the oldest oopses which, if the pstore is big enough, shouldn't have anything to do with the next set to be written. So, basically designing the pstore as a big enough circular buffer should suffice, no? This would even alleviate the need for the notification heuristics and writeout to userspace. Hmm... -- Regards/Gruss, Boris.