Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760548AbYHAWF5 (ORCPT ); Fri, 1 Aug 2008 18:05:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754174AbYHAWFs (ORCPT ); Fri, 1 Aug 2008 18:05:48 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:51635 "EHLO e6.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753698AbYHAWFq (ORCPT ); Fri, 1 Aug 2008 18:05:46 -0400 Subject: Re: [PATCH 1/6] Container Freezer: Add TIF_FREEZE flag to all architectures From: Matt Helsley To: Cedric Le Goater Cc: Nigel Cunningham , Andrew Morton , "Rafael J. Wysocki" , Paul Menage , Li Zefan , Linux-Kernel , Linux Containers , linux-pm@lists.linux-foundation.org, Pavel Machek , "Serge E. Hallyn" In-Reply-To: <4893025D.9090801@fr.ibm.com> References: <20080801050659.924495279@us.ibm.com> <20080801050700.261080433@us.ibm.com> <1217586735.27551.22.camel@nigel-laptop> <4893025D.9090801@fr.ibm.com> Content-Type: text/plain Organization: IBM Linux Technology Center Date: Fri, 01 Aug 2008 15:05:25 -0700 Message-Id: <1217628325.25300.270.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 14210 Lines: 328 On Fri, 2008-08-01 at 14:32 +0200, Cedric Le Goater wrote: > Nigel Cunningham wrote: > > Hi. > > > > On Thu, 2008-07-31 at 22:07 -0700, Matt Helsley wrote: > >> This patch is the first step in making the refrigerator() available > >> to all architectures, even for those without power management. > >> > >> The purpose of such a change is to be able to use the refrigerator() > >> in a new control group subsystem which will implement a control group > >> freezer. > > > > Is there a reason for always using 19, rather than just the next > > available bit? > > At the time I did the patch, it was to be consistent with the other > arches supporting suspend but this can not be true anymore. So we might > as well just use the next available bit as you suggest. > > Thanks, > > C. This is a good point. I did a quick survey of the thread_info*.h headers. Most archs appear to use the MSW/LSW to distinguish "pending work-to-be-done" (LSW) vs. other flags (MSW). This explains most of the gaps in thread flag assignment. In some other cases the bits are allocated based on whether the arch asm code uses asm immediate values to test the flag. sparc64 is by far the most elaborate and includes some excellent comments to explain the situation. The gaps in allocated flag bit assignments not explained in thread_info*.h comments are: mips doesn't use bit 0, there's a gap between 4 and 9, and another gap between 24 and 31. m32r has a gap between bit 4 and bit 8. ia64 has a gap at bit 5. blackfin doesn't explicitly mention the MSW/LSW distinction but appears to follow it. arm also doesn't mention MSW/LSW but appears consistent with that explanation. avr32 makes the MSW/LSW distinction but this doesn't fully explain jumping from bit 8 to bit 30 unless they're allocating numbers in the opposite direction within the MSW (highest flag is bit 31). m68k starts at 6 and the comments don't explain why. At first glance it doesn't appear to be because of m68knommu. It also jumps from bit 7 to bit 14 without explanation and appears to not follow the MSW/LSW convention. cris has an inexplicable gap between bit 3 and bit 9. s390 has a gap at bit 1. It appears to follow the MSW/LSW distinction but doesn't mention it in a comment. x86 has a gap at bit 9. "sparc32" has a gap between 4 and 8. So I've modified the flag numbers to follow apparent conventions of each arch as best I can tell given the lack of explanation above. ------------ From: Cedric Le Goater Subject: Container Freezer: Add TIF_FREEZE flag to all architectures This patch is the first step in making the refrigerator() available to all architectures, even for those without power management. The purpose of such a change is to be able to use the refrigerator() in a new control group subsystem which will implement a control group freezer. Signed-off-by: Cedric Le Goater Signed-off-by: Matt Helsley Acked-by: Pavel Machek Acked-by: Serge E. Hallyn Tested-by: Matt Helsley --- arch/parisc/include/asm/thread_info.h | 2 ++ arch/sparc/include/asm/thread_info_32.h | 2 ++ arch/sparc/include/asm/thread_info_64.h | 2 ++ include/asm-alpha/thread_info.h | 2 ++ include/asm-avr32/thread_info.h | 1 + include/asm-cris/thread_info.h | 2 ++ include/asm-h8300/thread_info.h | 2 ++ include/asm-m68k/thread_info.h | 1 + include/asm-m68knommu/thread_info.h | 2 ++ include/asm-s390/thread_info.h | 2 ++ include/asm-um/thread_info.h | 2 ++ include/asm-xtensa/thread_info.h | 2 ++ 12 files changed, 22 insertions(+) Index: linux-2.6.27-rc1-mm1/arch/sparc/include/asm/thread_info_32.h =================================================================== --- linux-2.6.27-rc1-mm1.orig/arch/sparc/include/asm/thread_info_32.h +++ linux-2.6.27-rc1-mm1/arch/sparc/include/asm/thread_info_32.h @@ -139,6 +139,7 @@ BTFIXUPDEF_CALL(void, free_thread_info, #define TIF_POLLING_NRFLAG 9 /* true if poll_idle() is polling * TIF_NEED_RESCHED */ #define TIF_MEMDIE 10 +#define TIF_FREEZE 11 /* is freezing for suspend */ /* as above, but as bit values */ #define _TIF_SYSCALL_TRACE (1<