From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7019DC27C4F for ; Fri, 21 Jun 2024 19:13:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F03D78D0195; Fri, 21 Jun 2024 15:13:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB30D8D0183; Fri, 21 Jun 2024 15:13:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D52C68D0195; Fri, 21 Jun 2024 15:13:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B760A8D0183 for ; Fri, 21 Jun 2024 15:13:30 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 56EBE160A2B for ; Fri, 21 Jun 2024 19:13:30 +0000 (UTC) X-FDA: 82255844580.19.C9AED8F Received: from out-172.mta1.migadu.com (out-172.mta1.migadu.com [95.215.58.172]) by imf29.hostedemail.com (Postfix) with ESMTP id 99201120016 for ; Fri, 21 Jun 2024 19:13:27 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=E1WGfEEj; spf=pass (imf29.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.172 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718997202; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4Oujy0oSP3uMXwSsfsYtQmtVOILqUaJG66ZF3sUiG6E=; b=qWERALnl3six/UfijytulcNKP8CtUIUH5De1B2//7tnFnav24Px8uenjNoawYwXp3Vu41K KCud0UiHjw0msNrUpCyjgobQHCCpGONTi37xIZt+GPXFsToGCNmHxQsmMVPi1Wa+lQ3E90 vs/Aur1d12EBhDq6843kx0dwZca4qVg= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=E1WGfEEj; spf=pass (imf29.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.172 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718997202; a=rsa-sha256; cv=none; b=VPYDu6ZioBFRR1JWJVAW1Gb5Xx1SednDOTwdDnSsnao4RRD31K2oct2RfW6Ys/8OkStoMR IPNHbOhca6LO68SObHZ6wrtmCsmDy8EHhHOwAoIUUeowU+ofU0DUYCUuq+s4V+qOFwx9JE n2MKFRurFI65VwLXufup/JioCkma69M= X-Envelope-To: bigeasy@linutronix.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1718997205; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4Oujy0oSP3uMXwSsfsYtQmtVOILqUaJG66ZF3sUiG6E=; b=E1WGfEEj1m0wKQeguY0KV1azICuphvzSpxbDM8sLHVh/NVTwXM3rsCocq/4ne8YjCVZNN1 hOUVX2cqWpda6Gd4kEaQkK75gKKW01vUljXvYYn+lmf/VzZ/knK4rOYqyNsRB1A4nZELd5 6MQQQp5avQjjaVb+YspAv/CA/Zp2YAo= X-Envelope-To: linux-mm@kvack.org X-Envelope-To: linux-kernel@vger.kernel.org X-Envelope-To: akpm@linux-foundation.org X-Envelope-To: bsegall@google.com X-Envelope-To: bristot@redhat.com X-Envelope-To: dietmar.eggemann@arm.com X-Envelope-To: mingo@redhat.com X-Envelope-To: juri.lelli@redhat.com X-Envelope-To: klarasmodin@gmail.com X-Envelope-To: mgorman@suse.de X-Envelope-To: peterz@infradead.org X-Envelope-To: rostedt@goodmis.org X-Envelope-To: surenb@google.com X-Envelope-To: tglx@linutronix.de X-Envelope-To: vschneid@redhat.com X-Envelope-To: vincent.guittot@linaro.org Date: Fri, 21 Jun 2024 15:13:19 -0400 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Sebastian Andrzej Siewior Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Ben Segall , Daniel Bristot de Oliveira , Dietmar Eggemann , Ingo Molnar , Juri Lelli , Klara Modin , Mel Gorman , Peter Zijlstra , Steven Rostedt , Suren Baghdasaryan , Thomas Gleixner , Valentin Schneider , Vincent Guittot Subject: Re: [PATCH] sched/task_struct: Move alloc_tag to the end of the struct. Message-ID: References: <20240621102750.oH9p1FQq@linutronix.de> <7zretxxixkpfxt6lr7x64n67ql2v2qpb7abbbjklclwlu4u2kx@22o5sdlnpkea> <20240621182915.S-ULWn0O@linutronix.de> <20240621190719.TeLTxI9M@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240621190719.TeLTxI9M@linutronix.de> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 99201120016 X-Stat-Signature: ugyq9xcfdkakkwybpeqxgjkgzpj1u89h X-Rspam-User: X-HE-Tag: 1718997207-836832 X-HE-Meta: U2FsdGVkX1+tQZ4E/K42MzKrZ9Xoqe2+h74jaTMp7akc59evXufKRxJxIUoxKB6dcypqgy6DiP5kypJrJs44Xol5tGyYciYCJIOqLp2CVc3hsUmf2Rd2PYKu7QsTdu7P0N7utancNnZnS80bCrU90m+HATV0+3+dq4VjAsNJate91g8vNry0pS0yK+SjAYTId6jZwRSt6qLW1bpW+NYyoph13g8T6ASBjT0LhSBdFWiAxP3SH/j7Xho0YvO902OFIb6YiyKJE+7jFDArx++y5irjp2YStYPi+SBtR9dUWzFvfWei01grLqPImcGuY0RiMTfL5i2wd6O1LKVqfQrJoShRtQ+MHCOd3XBXe0WfUseYZadzdQRxzozbwl9ZWV8ReE1UUpzmUf2DtZ7c6j46I3l/BtnH3oznqSpHmAcOOOcmgTD58DOCVHikKJ9Q2RXXmVUIXqnrEhmSqk8tDnarvAJFCkjMyoDt43UuExUCJireHzjACO4SEeZrtGylUJaxaDxoOpb/KrXDAF4Sc8Qh8EYFiPHxetI3NBRbblnVXVsQhcUN1ySquqHDgxqANzgaB9GRDrVsegeerLVnwhFORAwsnCvRULmLA/9FBA4OJhAF21rkYO9+oggkQKMfV//erjMPPhrVaG/akuUAkzOSBP7TEeARN37l03P6Lz54/71gzEf3XsaLoSq+ZTs2FgenD2bwSugzreFOWqjbt+c9BJs5dEYjH+BbgffBb+wHefh3npd1oHFX1DvjiUK74wXWZgDx7FTfuC6m+hAReIqGEy9DPjLt9jyu5eca3/35qk9n4REPur7tBHfok9oMFsi4uBlwAO0OiQZBmzPwn7rcZTY2av4uKgAolCg47ebODodOOp7vM6cg7xDfQ80B+UTFCdaddGOdT8igXkOEBxissnO5D9jXhJMGYqkk/BLv6p/Ms4mLQ0KqUDBRGSwgBKEa0r8APckJu+blTKN4E7r KIHcF6a0 uUjVU38Vo1LTGjPIbI+Jgti5V73FP6sAH0Ezm3MIM8hsjqNi1IgLu/vtjR5fuc8IzE3QDbvz6fQGFNCKxPi1oZDfSFPVK2PPSGMMXp6eJYMV++1SUUFAhmyPnR3hUlUnQkiJpSqxVBhOr+Ekmlfs3FFKOYcyyt8QvM3IOE6NHfu2VmxVRvWLBtbelbjAz4r4OJrjV X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Jun 21, 2024 at 09:07:19PM +0200, Sebastian Andrzej Siewior wrote: > On 2024-06-21 14:49:23 [-0400], Kent Overstreet wrote: > > On Fri, Jun 21, 2024 at 08:29:15PM +0200, Sebastian Andrzej Siewior wrote: > > > On 2024-06-21 10:20:58 [-0400], Kent Overstreet wrote: > > > > On Fri, Jun 21, 2024 at 12:27:50PM +0200, Sebastian Andrzej Siewior wrote: > > > > > The alloc_tag member has been added to task_struct at the very > > > > > beginning. This is a pointer and on 64bit architectures it forces 4 byte > > > > > padding after `ptrace' and then forcing another another 4 byte padding > > > > > after `on_cpu'. A few members later, `se' requires a cacheline aligned > > > > > due to struct sched_avg resulting in 52 hole before `se'. > > > > > > > > > > This is the case on 64bit-SMP architectures. > > > > > The 52 byte hole can be avoided by moving alloc_tag away where it > > > > > currently resides. > > > > > > > > > > Move alloc_tag to the end of task_struct. There is likely a hole before > > > > > `thread' due to its alignment requirement and the previous members are > > > > > likely to be already pointer-aligned. > > > > > > > > We sure we want it at the end? we do want it on a hot cacheline > > > > > > Well, the front is bad. > > > Looking at pgalloc_tag_add() and its callers, there is no task_struct > > > touching. alloc_tag_save()/restore might be the critical one. This is > > > random code… Puh. So if the end is too cold, what about around the mm > > > pointer? > > > > Not there, that's not actually that hot. It needs to be by > > task_struct->flags; that's used in the same paths. > > But there is no space without the additional 52 bytes. Was this by any > chance on purpose? No, that wasn't, and it doesn't have to be the exact same cacheline, but we do want it near current->flags; we store PF_MEMALLOC flags there that are converted to gfp flags and used exactly where we're using current->alloc_tag.