Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757177AbcC2MXe (ORCPT ); Tue, 29 Mar 2016 08:23:34 -0400 Received: from mail-ig0-f195.google.com ([209.85.213.195]:35922 "EHLO mail-ig0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756956AbcC2MXc (ORCPT ); Tue, 29 Mar 2016 08:23:32 -0400 MIME-Version: 1.0 In-Reply-To: <20160329094454.GA4715@gmail.com> References: <1458830281-4255-1-git-send-email-fweisbec@gmail.com> <20160325084847.GA15235@gmail.com> <20160325131732.GA16488@lerouge> <20160329094454.GA4715@gmail.com> Date: Tue, 29 Mar 2016 07:23:31 -0500 X-Google-Sender-Auth: bREohFlJ1h4BB38yMYRxNyqGtDQ Message-ID: Subject: Re: [PATCH 0/3] nohz: Convert tick dependency mask to atomic_t From: Linus Torvalds To: Ingo Molnar Cc: Frederic Weisbecker , LKML , Peter Zijlstra , Thomas Gleixner , Andrew Morton Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 912 Lines: 34 On Tue, Mar 29, 2016 at 4:44 AM, Ingo Molnar wrote: > > Harmonizing thread_info::flags does not look easy, given how much assembly code > accesses this field. It might not be too bad. For 32-bit architectures (which is still most of them), it's just a unsigned int/long -> atomic_t and for 64-bit architectures you end up with three choices: - it's already 32-bit (alpha, ia64, x86): unsigned int -> atomic_t - little-endian long: atomic_t flags unsigned int padding; - big-endian long (only powerpc? Maybe there's a big-endian MIPS still?) unsigned int padding; atomic_t flags; so you could do that fairly mindlessly. You *could* even use a nasty macro from hell to do it automatically, with the above rules in some . Then each architecture could clean itself up and get rid of the padding field if they want to. Linus