Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757065AbcJMWAV (ORCPT ); Thu, 13 Oct 2016 18:00:21 -0400 Received: from mail-vk0-f54.google.com ([209.85.213.54]:35126 "EHLO mail-vk0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753528AbcJMWAN (ORCPT ); Thu, 13 Oct 2016 18:00:13 -0400 MIME-Version: 1.0 In-Reply-To: <20161013115712.29517-1-heiko.carstens@de.ibm.com> References: <20161013115712.29517-1-heiko.carstens@de.ibm.com> From: Andy Lutomirski Date: Thu, 13 Oct 2016 14:52:52 -0700 Message-ID: Subject: Re: [PATCH 0/3] THREAD_INFO_IN_TASK_STRUCT vs generic preemption code To: Heiko Carstens Cc: Andy Lutomirski , Peter Zijlstra , Linus Torvalds , Ingo Molnar , "H . Peter Anvin" , Mark Rutland , linux-arch , "linux-kernel@vger.kernel.org" , Martin Schwidefsky 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: 1450 Lines: 39 On Thu, Oct 13, 2016 at 4:57 AM, Heiko Carstens wrote: > Commit c65eacbe290b ("sched/core: Allow putting thread_info into > task_struct") made struct thread_info a generic struct with only a > single flags member if THREAD_INFO_IN_TASK_STRUCT is selected. > > This change however seems to be quite x86 centric, since at least the > generic preemption code (asm-generic/preempt.h) assumes that struct > thread_info also has a preempt_count member, which apparently was not > true for x86. > > We could add a bit more ifdefs to solve this problem too, but it seems > to be much simpler to make struct thread_info arch specific > again. This also makes the conversion to THREAD_INFO_IN_TASK_STRUCT a > bit easier for architectures that have a couple of arch specific stuff > in their thread_info definition. OK, I give in. But can you coordinate with Mark, because I think I convinced him to do it a little differently? I might be changing my mind a bit for an evil reason. Specifically, on x86_64, we could do the following evil, horrible thing: union { u64 flags; struct { u32 atomic_flags; u32 nonatomic_flags; } }; Then we could read and test the full set of flags (currently split between "flags" and "status") with a single instruction, and we could set them maximally efficiently. I don't actually want to do this right away, but making thread_info fully arch-controlled would allow this. --Andy