Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 12 Jul 2023 15:36:27 +0530
From:   "Gautham R. Shenoy" <gautham.shenoy@amd.com>
To:     David Vernet <void@manifault.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        linux-kernel@vger.kernel.org, mingo@redhat.com,
        juri.lelli@redhat.com, vincent.guittot@linaro.org,
        dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com,
        mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com,
        kprateek.nayak@amd.com, aaron.lu@intel.com, clm@meta.com,
        tj@kernel.org, roman.gushchin@linux.dev, kernel-team@meta.com
Subject: Re: [PATCH v2 6/7] sched: Shard per-LLC shared runqueues
Message-ID: <ZK57IxhhZMw2ZaEA@BLR-5CG11610CF.amd.com>
References: <20230710200342.358255-1-void@manifault.com>
 <20230710200342.358255-7-void@manifault.com>
 <20230711104958.GG3062772@hirez.programming.kicks-ass.net>
 <20230711195757.GD389526@maniforge>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230711195757.GD389526@maniforge>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?OKyPQ9RSV/hxNiPm5XN12hzaWwgybOSxfgUqvr61lzFeobLd2l7LIdmz7gI3?=
 =?us-ascii?Q?kkgTW6Q/Xe+F15SZZXZuazLE0uc2Lp8LNswKWbo9vxXNQUQLMZp2GwgW2YJB?=
 =?us-ascii?Q?LV+aCFnVBFOdyQqM5xU7cHqTT19UjBX6GF+dTGW2v/A3riMWYMDMb/7wzEmz?=
 =?us-ascii?Q?MZd3oL6eYCvLu7bSwqfxhmdGMY5SBwTJNPAJcxipHYbei4pn84wRbVXQyS2M?=
 =?us-ascii?Q?m9CO6mP77MsVd1ic1W+Ar0/Btr1tsMol4cweWKQl+u4VAG4dwHglDuN0jBz1?=
 =?us-ascii?Q?MK7D9DOQADTYXwySNcZc504XU78hffaoL8o+GSCfu2oVi1l/+lOzU/L9nFoI?=
 =?us-ascii?Q?5/GLJQF0bL8hN/sVcRK4LvjtuDH9Sc/3ocnw89UalFEQhNyvjbNJydQDoxWl?=
 =?us-ascii?Q?acGZAnIDNkVzXs437xxh9rFxE10AEGIkXbmrJ5OpEBXIxV0JvfQSaWSsXhlc?=
 =?us-ascii?Q?itqVDjHh5YYYFyeT48mMjZxSwXNYnTXCl+WLLEsjqc+1BCArCZG23igpA3QJ?=
 =?us-ascii?Q?+LQyUTwJUYv2ck3BSVYHpgtmH5qfFFsW7mPxIF3GvvCD1xa+/t2t+QxjWIIZ?=
 =?us-ascii?Q?UnJ6Jp6V8TlMguq6HEtIT+j1jBoOIKcj8T6NOUwjimDhLpzvZpIIpgB85hRF?=
 =?us-ascii?Q?ev77M6bw1vGE4Xh4sv2w6Hq+QCXspibsrOunuXIDwvg+gn29ZI+bplZe9p8P?=
 =?us-ascii?Q?3zBMglCgxwTgTBJZYhI891qUHqABtnbNHzcPbc6YsYYNq/a00nltc26fSD8K?=
 =?us-ascii?Q?fVPBqg/zFGQ7Z1ut9tJWntvJOE0G6KR23zY9uEtH3V8ZKh+piYNK0C39i0o4?=
 =?us-ascii?Q?H6czrGQ0mCGr+k3nwSOuy1ILMzI9MIR69mUBvcrStKmwg0em4S0V5phG1AmF?=
 =?us-ascii?Q?fUbrzVptxU4lr99mUo9wK97TqMLS09Ipm9XWQWgQ4WsOj3UDD0HK8UQ4ziKX?=
 =?us-ascii?Q?tDmz1dwiqhhVARpAIaTJDvl9hQtQra36j+lBVAeVlOdTIrLWyIcaJMKY/Jtb?=
 =?us-ascii?Q?qN6xo/RbfNDg/8n15K6El2zzhFbd4CmkYsrSrVWlv924Mg7H4qzm5W8Bp035?=
 =?us-ascii?Q?aYdqNVOXW0YbZjfwHSBywzQPuDCy0arSbBK0Y+4GGp2BckRS1FXjLQ6eSdd3?=
 =?us-ascii?Q?U7yY850KGZTw5RyhNhNg6LAo57Rq6mEosLX7si0lNIcwNjVj5luRbJm/lB99?=
 =?us-ascii?Q?aCkBAXNlMDCOFV++hdQWsd7496KlxnqhVk7oBz8sBMPYHoKLAtQpaPkhOBfZ?=
 =?us-ascii?Q?5SH5xTcuY5LburCSuZ1rMvpmU2hmwbVCgWkNuGUDNIDgSAKM4ADDh4LYlyBy?=
 =?us-ascii?Q?DrvrlZ/AMZ8uakW5+Q7Ub3xqPEYLy2j5lwREAwYMJxIB+M4NNw8F80MRURF6?=
 =?us-ascii?Q?ZWDsgPReWslpVBR/r3CoiqgVH3UDbRr/JTqnfMAFwPt1K9UwXqq67L8alAbW?=
 =?us-ascii?Q?g+1DZa6kJJzJ7+Hd608zQXYWr8teQ4+PDy7OMSwf8v0rzpJtniv29EFMQjdE?=
 =?us-ascii?Q?X+B1XrRO2jn1spKGjH3QFTJmP8SgEDAxL6PyAI8uJJyV3Orl9tRMMtY8xv1w?=
 =?us-ascii?Q?8sdsZXkRVhCjb6Ty2bpT7TLWCaQSa3Cf1VkiMZHD?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d8626e06-eb0d-4850-b789-08db82bfb490
X-MS-Exchange-CrossTenant-AuthSource: DS7PR12MB8252.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jul 2023 10:06:48.6870
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: rOIx+wc9uG0PsH6yrC1ou4DM4dIur7vpK/M58yu7+j68PyUn1PYwicoUE9Oaivg2krPdgLgPF6fUz5d7cIHuqw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB9092
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=no autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Jul 11, 2023 at 02:57:57PM -0500, David Vernet wrote:
> On Tue, Jul 11, 2023 at 12:49:58PM +0200, Peter Zijlstra wrote:
> > On Mon, Jul 10, 2023 at 03:03:41PM -0500, David Vernet wrote:

[..snip..]

> > > +static int shared_runq_shard_idx(const struct shared_runq *runq, int cpu)
> > > +{
> > > +	return cpu % runq->num_shards;
> > 
> > I would suggest either:
> > 
> > 	(cpu >> 1) % num_shards
> >
> > or keeping num_shards even, to give SMT siblings a fighting chance to
> > hit the same bucket.
> 
> Given that neither of these approaches guarantees that the SMT siblings
> are in the same bucket, I'll just go with your suggestion which is
> simpler.
> 
> Seems inevitable that we'll want to have another debugfs knob to adjust
> the number of shards, but IMO it's preferable to just apply your
> suggestion in v3 and hold off on adding that complexity until we know we
> need it.
> 
> > (I've no idea how SMT4 (or worse SMT8) is typically enumerated, so
> > someone from the Power/Sparc/MIPS world would have to go play with that
> > if they so care)
> 
> Yeah, no idea either. If these things end up varying a lot across
> different architectures then we can look into making shard assignment
> architecture specific.

On POWER, the SMT siblings are enumerated in a sequential fashion, i.e

CPU id of a thread = Core_id * threads_per_core + thread_id_within_core.

But IIRC, POWER sets L2 domain as the LLC. On POWER8 (with SMT8) and
POWER9(with SMT4 on Baremetal and SMT8 on VMs), LLC size is 8. Even
with SHARED_RUNQ_SHARD_SZ = 6, there will only be 1 shard with the
current formula

	num_shards = max(per_cpu(sd_llc_size, i)/SHARED_RUNQ_SHARD_SZ, 1);

(Aside: with the above formula, on a topology with 6 < sd_llc_size <
12, num_shards will remain 1, with the shard size exceeding the
intended SHARD_SZ. Was this the intention ?)

Even on x86, there is no uniformity in how the SMT threads are
numbered. On AMD EPYC Baremetal, the first threads of all the cores
are enumerated first and then the sibling threads. So, on an EPYC
server with 128 cores in total, the SMT sibings are {0,128}, {1, 129}, ...

With SHARED_RUNQ_SHARD_SZ = 6,

On Zen2 EPYC Baremetal, with LLC size = 8, num_shards = 1.  This
simplifies stuff!

On Zen3, Zen4 EPYC Baremetal, with LLC size = 16, num_shards = 2.

Here, (cpu % num_shards) ensures that the SMT siblings belong to the
same shard along with 3 other cores.

On some Intel servers, it is possible that the CPU numbers are
interleaved across the two sockets. On my 2 socket, 32Cores per socket
Ice Lake Server, all the even numbered CPUs are in one socket and all
the odd numbered CPUs in the other socket.

The SMT siblings are {0,64}, {2, 66}, .... on one socket and {1, 65},
{3, 67}, .. on the other.

On this system, LLC size = 64. With SHARED_RUNQ_SHARD_SZ = 6,
num_shards = 10.

So with (cpu % num_shards) the siblings {0, 64} ... will belong to
different shards.

What would be good to have is

1. shard_size determined by individual architectures. If none is
   provided, we pick the default shard_size.

2. A sharding scheme which guarantees that SMT siblinngs will belong
   to the same shard as long as shard_size is at least as big as the SMT
   size.

--
Thanks and Regards
gautham.