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 25391C4829A for ; Sat, 10 Feb 2024 07:53:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 65D8B6B006E; Sat, 10 Feb 2024 02:53:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 60D316B0072; Sat, 10 Feb 2024 02:53:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D5436B0074; Sat, 10 Feb 2024 02:53:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3B07F6B006E for ; Sat, 10 Feb 2024 02:53:06 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D839FA26B4 for ; Sat, 10 Feb 2024 07:53:05 +0000 (UTC) X-FDA: 81775128330.09.3D193D3 Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) by imf22.hostedemail.com (Postfix) with ESMTP id 34C97C0005 for ; Sat, 10 Feb 2024 07:53:04 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kpwTZvO5; spf=pass (imf22.hostedemail.com: domain of elver@google.com designates 209.85.217.50 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707551584; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=oh7b21hgViH6ruD4OjEdfH5S4LaVkUGIxCxXRvf2xsc=; b=PwahYQOhdC7zmlLTpF5qpXw3c2lHtNWx/inUBybAaRaT1JVRIliyLM+oseTVcD5AmjDL+k /x8vjjsVX2mofoAdQtXgXWMcRutvZR2Q83xtqGy0EMFFJWLToy84Llz4iRpx065BhYnMHf P3Ui+KxeJPJRsB+uyuqJlNXqsG7ciRc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707551584; a=rsa-sha256; cv=none; b=VpK74TVqEAK98nmdn3dRVj51tORku9bQaiUTTAufal1N3trZTI0XiJYUT+H97HNaind1lp Enq1nT2LZu6+hcm8AzSvrpwbMgpQsXU4Ilj7vsrjiNurpoVVWo5CtXMncrHlWRPo+pIcCF hn4Og/InylNt2ruEdYD7RJxeY3icoi0= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kpwTZvO5; spf=pass (imf22.hostedemail.com: domain of elver@google.com designates 209.85.217.50 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-vs1-f50.google.com with SMTP id ada2fe7eead31-46d2635b15eso1650464137.1 for ; Fri, 09 Feb 2024 23:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707551583; x=1708156383; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oh7b21hgViH6ruD4OjEdfH5S4LaVkUGIxCxXRvf2xsc=; b=kpwTZvO5dEUf2Q+jcfj+zU+oAHFgGswHQbrVkHq5cGfmG/DnZvW8zhrVEcAxCF8LGS FoQ4DJN9lkAvo4MRExn5/lezvIgWmqrBQ1KwrlAFeXMJSiwfnpSLzV8NmV6iWZkZtoA5 kWTzZEPfRQE5ebIiptiqKwnZl1GCs293ZuK6+8eET5E419kqHg8M6eKb86eH1cU4XHYD 2I/efchUVHsA92YgOfwWS4U5Y+fYcANfRfHE3JX+HSdPCc+kFfVCJEZLh4b8sbqX1x/M 4rYiv1TFQf9D2OxF/J4M/xmwiPMKYK8Ya/mbQFHDRTCF/j5S69KrqbI+dAXyCkXXtoSS ukKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707551583; x=1708156383; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oh7b21hgViH6ruD4OjEdfH5S4LaVkUGIxCxXRvf2xsc=; b=Jxkr0bMPWnVA1cxLbhbdlullvK3aGPcWNifREJloZgUOmQRD9yOJ4d36mQx+Cjq2t2 Ea1IL9XV2q4NrWbwsOitoqg5pmKgoXbLkrFK3Vk2PPOCmr6KulJ2c9bThOqAcZKAPq2T EWciGc/5CZb8qbOy0Q14aATBcvWsD4N1vfjvsTgmyU/wg6hV+kqnAmhe3FSg7v1fy528 0sNISDJ+NggthiHtFDHTfmDRavH0V1j741PHf/IOiLnK3XCaHDrWTVY6xORNCFxIKY80 GA30plpGPJhJIFvE7uE3HUX1odTH4ink6l4VmeDEAnOJ4f7xQs6XRI7SO0kegxgrIt4B UFpQ== X-Gm-Message-State: AOJu0YwmaZXLVemGEqDFpAbxnyhdXHtZ8ElauUoKrccQKaBOM6JTcJJ/ FIvICVOvvyC54ob7sylBZB1v71oW0uEdat5h6g+q/bUMV5EZMxNONNUalUd7ox/V9ATmxogvp3e h2Jxtf5yKVaNbRHP8Is4BLI4/+N21YqodusgJ X-Google-Smtp-Source: AGHT+IEy5rUmGLmkkY3OAPFo9Hk+pfbInuFkdngpUfw0cdyQRm4JJclp/RrYVG0JQ72JVRTrm/4TEUFpxSUyyzFVwAU= X-Received: by 2002:a05:6102:548c:b0:46d:2f69:c772 with SMTP id bk12-20020a056102548c00b0046d2f69c772mr1600399vsb.11.1707551583163; Fri, 09 Feb 2024 23:53:03 -0800 (PST) MIME-Version: 1.0 References: <20240208234539.19113-1-osalvador@suse.de> <20240208234539.19113-4-osalvador@suse.de> In-Reply-To: From: Marco Elver Date: Sat, 10 Feb 2024 08:52:25 +0100 Message-ID: Subject: Re: [PATCH v7 3/4] mm,page_owner: Display all stacks and their count To: Oscar Salvador Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Vlastimil Babka , Andrey Konovalov , Alexander Potapenko Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 34C97C0005 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 8zzuh8i7crtd351uh4gg37497apkg6f5 X-HE-Tag: 1707551584-312626 X-HE-Meta: U2FsdGVkX1/xUjYTn5/8nvEsySvBNkVVmBSNdLuOlP8+F+gmPc4s7EsV5j/mVFp7jgcmmgfX38HhSzSyZrpDMkfG7XmVaLOvSelCjC43P2IS/5jmWPLuT0EykSOHd+zmwyvNygiXvlxVtfjc45MrwdLF3Pq5S0w2cD7eCkN6MIIYexrx+xQMygUZ7zPSpSIdBQja6dut13yeZ9r3AhnNpPvRXT3oHdZmWhF4aM1Q/e4N3aJx5NV76sZ4FeH114Y4LdpEbDeoqdm9kJz23YTbZjPqUCvxCCkvzEXltNOTM6wXIzQFEigZAaHbge2ted027YKbOcJtaeb9ozZ0Qx/ri07J1nZ1BIl3uHodAqqpg8rdy3v9gZTESW9HzbMHnW+RC7rXZuFU312FhFQNMPjfytV7FKNAOtEOq94rSHAWzrheDQHVWTZdqnvorr8K0Y7tQg1xQkd10W6QQkZvaC1WqhLY7glxbBAtWE7Eet8r7r7oWcOhQIiarW0HxoeKCaSWCpzrHslrpX/AukLAICGvs+NQyGRqlRPPyQP/+bjoGTRr4mk8kAoDmW5MyTmWgubQPCG2U2PbfdLLbpvR16rT2v2L6WMg3+B9iLIIm9t7ar4OvjXVIHcj+U7tcDEI4MfXdSP5asK/+u6llwayEV6kPcTqGvU/1yC8oIGjFu0hXQiEpGNs7ZbxPE6vdGZdgesRwIzWTg/GmReWyaok+M+zdy90DbtwMShwf+mwyieENRKF6OIAwVev00WYmbssxcNXVN7At1jT5WUZNJPFXiJa+WKxoodfJdn6VpSXCJl9GNgiMx1kTN1n2cOKwIzhCAopfh7i0Zg6ox1SRd//LA+VV1V1bLYeQ0k7aCIbrbTlL3g7tlsVnI3s9RuRot8fHQ4kmKQqyW3sr86SuSEqUpzoR3ZGQEUYGfhdGX6IkcDXU0gLNs3n9+q4nRyCAXUpanx1N6G0LhV9pOy83XLEMbw 3uUiRAj7 zAEBbidgTxlfE9zX8ExrU/HAn0ctGXnjNNNk//2Uc/GAc6G0pTFPVNA03yJzTTkjk9W/taLSrM1zrTijpZbnN75JMhiHWN/qhjv3sl8aB6YIfI+ZKRcUcrgFlzhZOwn50SmUIvHMblyvY8itHYOI+A+xkyrl0Pe7t6WMMgPViVycWD1RIPSGABAz4gL3Xl2dqkDM0yYb8Z/T4Zgd6HzQFPcn5XaMW/wyrFnykl4hnloGIZtWcqwfcngbOq61UePDD0oHFxz6Gl0aJ5iM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000172, 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 Sat, 10 Feb 2024 at 00:13, Oscar Salvador wrote: > > On Fri, Feb 09, 2024 at 10:52:48PM +0100, Oscar Salvador wrote: > > Thinking about it some more, I think I made a mistake: > > > > I am walking all buckets, and within those buckets there are not only > > page_owner stack_records, which means that I could return a stack_record > > from e.g: KASAN (which I think can evict stack_records) and then > > everything goes off the rails. > > Which means I cannot walk the buckets like that. > > > > Actually, I think that having something like the following > > > > struct list_stack_records { > > struct stack_record *stack; > > struct list_stack_records *next; > > } > > Or, I could use the extra_bits field from handle_parts to flag that > when a depot_stack_handle_t is used by page_owner. > > Then __stack_depot_get_next_stack_record() would check whether > a stack_record->handle.extra_bits has the page_owner bit, and only > return those stacks that have such bit. > This would solve the problem of returning a potentially evictable stack > , only by returning page_owner's stack_records, and I would not have > to maintain my own list. > > I yet have to see how that would look like, but sounds promising. > Do you think that is feasible Marco? The extra bits are used by KMSAN, and might conflict if enabled at the same time. I think the safest option is to keep your own list. I think that will also be more performant if there are other stackdepot users because you do not have to traverse any of the other entries.