Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2220749ybe; Tue, 3 Sep 2019 09:34:46 -0700 (PDT) X-Google-Smtp-Source: APXvYqwKakCL0WfsKUsNdrXnhdIpgRioULmsEkBc0pW44BTTZzejUPK5xV/2A5Ss0fvE7Y79Xh67 X-Received: by 2002:a62:cec4:: with SMTP id y187mr8796017pfg.84.1567528486663; Tue, 03 Sep 2019 09:34:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567528486; cv=none; d=google.com; s=arc-20160816; b=mRgk8j44eyiYE5bK/7GxrYYYb6WJH+ERayBRs/YVbvK9ypOTN1OsvyoHfMvkPG1ygz jEa0Q/hNrFt3T7z2mXYJLgsz0lacRpjnU4YZ3y5D5fmqWY3LHQ/o+F3+OPluFZjYVQua DbK2m39CC0LUT4a4SLbcYJ9mvofvuhdIzm4KTuVJjjjKoYiZeEXIT1n1Sna2F44fnLDf QxjePBN/GSdAjjjSqXYqBjDyYNp+nbeyAbhMHTYc7fdfelDMd7l7v5ETP10GjD9ywAfA lAnYjGKh2O4yF72wDax0HQNegr6ztJjtnN4tO6X9MQtO3fPD3iwB9elP9hY/OTjhhObY Lijw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=lj+LlVdKrOExhstg0/NJFvvuxvQlI9al2S0QECph+sA=; b=Vra434VVIE5F3+DN7m7ebmsMAdA3bpimpjQMpK02SKBOOjX/KfD8WJbXaeE35v26yL VCwKzbvx+R3BfIGUm5rRutqDs2VhdTDrvpcHrQmkyn6sqfc4yR8sxW2EprheAMR/Tzoy Ux/EkMCBpCLdoOx7ifG6U9wuAFB8ZTflJWM+ArX3P1DXAJR8X6eHfzna4VTq/yw/OYXr vTnqRhvbEuuyJJqJS5GZLlUZlnVsNbV3dW1UIzifbbPkQrKcwJjSsCiBx8IBg+bBzWnH uHk/AOyOc5DT0e4l+sxKL4atW0d8PdpcH15skf1/yueKPSzGoAET25fb6TZyUBoNoGnC tQLg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w27si12217179pfj.214.2019.09.03.09.34.31; Tue, 03 Sep 2019 09:34:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731010AbfICQdr (ORCPT + 99 others); Tue, 3 Sep 2019 12:33:47 -0400 Received: from foss.arm.com ([217.140.110.172]:40480 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731200AbfICQbt (ORCPT ); Tue, 3 Sep 2019 12:31:49 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 80A9C360; Tue, 3 Sep 2019 09:31:48 -0700 (PDT) Received: from [10.1.194.37] (e113632-lin.cambridge.arm.com [10.1.194.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 59C973F246; Tue, 3 Sep 2019 09:31:47 -0700 (PDT) Subject: Re: [PATCH] sched: make struct task_struct::state 32-bit To: Alexey Dobriyan Cc: mingo@redhat.com, peterz@infradead.org, linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-block@vger.kernel.org, dm-devel@redhat.com, axboe@kernel.dk, aarcange@redhat.com References: <20190902210558.GA23013@avx2> <7b94004e-4a65-462b-cd6b-5cbd23d607bf@arm.com> <20190903162303.GA2173@avx2> From: Valentin Schneider Message-ID: <64003dcd-d954-b76d-856a-214ff11ac000@arm.com> Date: Tue, 3 Sep 2019 17:31:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190903162303.GA2173@avx2> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/09/2019 17:23, Alexey Dobriyan wrote: > On Tue, Sep 03, 2019 at 12:02:38AM +0100, Valentin Schneider wrote: >> struct task_struct { >> struct thread_info thread_info; /* 0 24 */ >> volatile int state; /* 24 4 */ >> >> /* XXX 4 bytes hole, try to pack */ >> >> void * stack; /* 32 8 */ >> >> Though seeing as this is also the boundary of the randomized layout we can't >> really do much better without changing the boundary itself. So much for >> cacheline use :/ > > Cacheline use of task_struct is pretty hopeless because of all the ifdefs. > Yeah I figured, then had a minute of silence for those forsaken bytes.