From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759629AbZBNXcp (ORCPT ); Sat, 14 Feb 2009 18:32:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759519AbZBNXbv (ORCPT ); Sat, 14 Feb 2009 18:31:51 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:49470 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761545AbZBNXbt (ORCPT ); Sat, 14 Feb 2009 18:31:49 -0500 Date: Sat, 14 Feb 2009 15:31:24 -0800 From: Andrew Morton To: Ingo Molnar Cc: Dave Hansen , orenl@cs.columbia.edu, linux-api@vger.kernel.org, containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, torvalds@linux-foundation.org, viro@zeniv.linux.org.uk, hpa@zytor.com, tglx@linutronix.de Subject: Re: [RFC v13][PATCH 00/14] Kernel based checkpoint/restart Message-Id: <20090214153124.73132bf9.akpm@linux-foundation.org> In-Reply-To: <20090214230802.GE20477@elte.hu> References: <1233076092-8660-1-git-send-email-orenl@cs.columbia.edu> <1234285547.30155.6.camel@nimitz> <20090211141434.dfa1d079.akpm@linux-foundation.org> <1234462282.30155.171.camel@nimitz> <20090213152836.0fbbfa7d.akpm@linux-foundation.org> <20090214230802.GE20477@elte.hu> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.5; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 15 Feb 2009 00:08:02 +0100 Ingo Molnar wrote: > > * Andrew Morton wrote: > > > Similar to the way in which perfectly correct and normal kernel > > sometimes has to be changed because it unexpectedly upsets the -rt > > patch. > > Actually, regarding -rt, we try to keep that in two buckets: > > 1) Normal kernel code works but is unclean or structured less > than ideal. In this case we restructure the mainline code, > but that change stands on its own four legs, without any > -rt considerations. > > 2) Normal kernel code that is clean - i.e. a change that only > matters to -rt. In this case we dont touch the mainline code, > nor do we bother mainline. > > Do you know any specific example that falls outside of those categories? > It happens fairly regularly. Problems with irqs-off regions, problems with preempt_disable() regions (came up just yesterday with a patch from Jeremy). Plus some convert-to-sleeping-lock conversions over the years which weren't obviously needed in mainline. Or which at least had -rt motivations. But that's different. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [RFC v13][PATCH 00/14] Kernel based checkpoint/restart Date: Sat, 14 Feb 2009 15:31:24 -0800 Message-ID: <20090214153124.73132bf9.akpm@linux-foundation.org> References: <1233076092-8660-1-git-send-email-orenl@cs.columbia.edu> <1234285547.30155.6.camel@nimitz> <20090211141434.dfa1d079.akpm@linux-foundation.org> <1234462282.30155.171.camel@nimitz> <20090213152836.0fbbfa7d.akpm@linux-foundation.org> <20090214230802.GE20477@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20090214230802.GE20477@elte.hu> Sender: owner-linux-mm@kvack.org To: Ingo Molnar Cc: Dave Hansen , orenl@cs.columbia.edu, linux-api@vger.kernel.org, containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, torvalds@linux-foundation.org, viro@zeniv.linux.org.uk, hpa@zytor.com, tglx@linutronix.de List-Id: linux-api@vger.kernel.org On Sun, 15 Feb 2009 00:08:02 +0100 Ingo Molnar wrote: > > * Andrew Morton wrote: > > > Similar to the way in which perfectly correct and normal kernel > > sometimes has to be changed because it unexpectedly upsets the -rt > > patch. > > Actually, regarding -rt, we try to keep that in two buckets: > > 1) Normal kernel code works but is unclean or structured less > than ideal. In this case we restructure the mainline code, > but that change stands on its own four legs, without any > -rt considerations. > > 2) Normal kernel code that is clean - i.e. a change that only > matters to -rt. In this case we dont touch the mainline code, > nor do we bother mainline. > > Do you know any specific example that falls outside of those categories? > It happens fairly regularly. Problems with irqs-off regions, problems with preempt_disable() regions (came up just yesterday with a patch from Jeremy). Plus some convert-to-sleeping-lock conversions over the years which weren't obviously needed in mainline. Or which at least had -rt motivations. But that's different. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org