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 82ED2CD98C0 for ; Tue, 10 Oct 2023 21:39:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 17D4A8E0001; Tue, 10 Oct 2023 17:39:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 12DA28D0002; Tue, 10 Oct 2023 17:39:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01B508E0001; Tue, 10 Oct 2023 17:39:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E5E128D0002 for ; Tue, 10 Oct 2023 17:39:50 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id BA9DD8024B for ; Tue, 10 Oct 2023 21:39:50 +0000 (UTC) X-FDA: 81330869340.11.3C206EF Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf06.hostedemail.com (Postfix) with ESMTP id D019C18001E for ; Tue, 10 Oct 2023 21:39:48 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=e1adgODi; spf=pass (imf06.hostedemail.com: domain of mingo.kernel.org@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696973988; h=from:from:sender: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=TsPRHA98FhrwhRKg+R8NI3J52+4rr5kRhI+cS2n4Rj0=; b=3DtTfV8ZGNbzBH3HpeUXaLGqA0Kq/OmSleg8qMcvOWekH/5yA+tKf7sXvPEntQAOnrwAlz TLCnx/7RnVCRG4DFnntVu3kwaA9JI81FkZmjL1IeeqZYuwJ4Vz80C0d2vIDgXvkez+iMW0 M7kxFxhvolusU6jeFZf3Rfyd6aVUO0Y= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=e1adgODi; spf=pass (imf06.hostedemail.com: domain of mingo.kernel.org@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696973988; a=rsa-sha256; cv=none; b=SQgFc3MEXmwYOgvEi1sP4CZBHMiSx5NW4woWywXrgpUXhG212tOxTkq+hwSKk3+nRvqtGj bwChy1VL48raNcVZFRTOFk06ylwBImWQHvGzkg5eLFW/R3GosI4w6Xd9kNvBI3ZIpv3JUC y8KAGf++kQ4i6NDZVHeCkbekzXw0AyU= Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-53808d5b774so10973547a12.3 for ; Tue, 10 Oct 2023 14:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696973987; x=1697578787; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=TsPRHA98FhrwhRKg+R8NI3J52+4rr5kRhI+cS2n4Rj0=; b=e1adgODihd9LbIP/cN/Lf7lePHqxAw61MjeZLVGM4QKFYelA/pRQKqqX0eVAHGvXZW lYvNkDc4mwt/TJZ5YS4s5s85NY0nYPmjPARJ+7ssVaUe6bemRySCFWDW3LYykzSt1oKg nBC9XWQygBLmH/DKF0ikIT5CfqjM0ZtEWSXeFzASfe6JFRyD9snIYEHrBWfofkHSBKuM LKms8YJPelZHGPTECJQDz7ecA3YPMbkmp3vCt+s8nKawHy7xxZbfTLsTzMhiXz9wnciR 8RyZmJ/8szMMmOKtFRx/zSvTCHTBKy1U3Wqa6HtsqCPcsq10vfmvWR3pUZRzxdJoWZYg Dtog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696973987; x=1697578787; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TsPRHA98FhrwhRKg+R8NI3J52+4rr5kRhI+cS2n4Rj0=; b=eZhLdJuojFWG9/6LqwO0Oc8YfWVN7/GPlbYncQrBnUmHzFmZOmOHH99DxOyWQ/Bm83 frxuzRspOBpdunlma+grFtUzRn8KiMJIinhPCJwne7mwTiR4vdXd/Oh6FPmcTxHpXreo qz09AvYuQ6glNORrvX33RpoSoXol4ka+5ku37rXmm5D3BEgjiiOAaWVN95UZ6kd4rOZ9 PHotq+IOWukR3LPu//cBW7GaPL+6RaikiO0A/ZYEwn6eG4SbvdqdJarNJi9Z1yAk90NP +jzhCa2rHHHeWSH5MFRVbjByAUa/bR2sUi3sVnwS6sEXRWLs2ZM8ddyDtwG7C8P4KfLB GAXA== X-Gm-Message-State: AOJu0YzQGZ5qQTPOFQsJx4xNbJQ5mml4Wnb+N5kuvwiTNYaivie2sqWw vVPMc6cknMbpvJMpii94lYk= X-Google-Smtp-Source: AGHT+IGGegVLPyhh3h38JMNISW7SFnz5Uc1hNzxwqw75DDhB58/1C33hiGKqcE2q8nY6tpDhfEn4Vg== X-Received: by 2002:a05:6402:60c:b0:531:35c4:8ca2 with SMTP id n12-20020a056402060c00b0053135c48ca2mr13383464edv.42.1696973987200; Tue, 10 Oct 2023 14:39:47 -0700 (PDT) Received: from gmail.com (1F2EF9FF.nat.pool.telekom.hu. [31.46.249.255]) by smtp.gmail.com with ESMTPSA id y20-20020aa7d514000000b00537708be5c6sm8191442edq.73.2023.10.10.14.39.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Oct 2023 14:39:46 -0700 (PDT) Date: Tue, 10 Oct 2023 23:39:44 +0200 From: Ingo Molnar To: Mel Gorman Cc: Peter Zijlstra , Raghavendra K T , K Prateek Nayak , Bharata B Rao , Ingo Molnar , LKML , Linux-MM Subject: Re: [PATCH 6/6] sched/numa: Complete scanning of inactive VMAs when there is no alternative Message-ID: References: <20231010083143.19593-1-mgorman@techsingularity.net> <20231010083143.19593-7-mgorman@techsingularity.net> <20231010095752.yueqcseg7p3xg5ui@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231010095752.yueqcseg7p3xg5ui@techsingularity.net> X-Rspamd-Queue-Id: D019C18001E X-Rspam-User: X-Stat-Signature: 5zby5ansfjy1mbnp5qsncug4e7hhkjp8 X-Rspamd-Server: rspam01 X-HE-Tag: 1696973988-567643 X-HE-Meta: U2FsdGVkX18x3n3JH0ESrd1pRJBwgylircVTt5yPWaV5vsUA6BAcE0jnArOBmcJFbLm8TyHMpnMRsAFbNeWhdMshQGrTlMU7Ccgn07winYWUX7Zu9dYicE2wtu3AWQdMaCZhvT3KkWc6kT5ynZU3wghokGVVmGzY36+yxwOrBX22C+q3hpoGEhqt0Uqw1sI6EPOyBC9mHIebkK2Wjb7NScKnuIsrlGZ+8POSNQpl5o87BSNB696V+CT43dYNZV/CdO/+XboL0AaMSxix0skDECPLLxKbRWDZPORTwNDbKDcaAGP0+numiZ4AqzFBi9s7A14wImzznmzIMtfipbcjW1Y77X9OyZAV90l5dYHIKpkZbwbVEYGJPtfMckfc1xJ6euCi/zpsxv8j98JKTCpiEr77TpPvJ9QwcYL3MFFNmYiV7jg+AqnyEL6qOprg1Z9zJhhpbLx4wfmx0cLylJFJBp7rnvaRxAN4xWlefq/O3nUMYMi4xMNoFI3NRoNUWvuzSWTd7/VNJKkG3jJ9Aducw7FKQ6K4vzafbZgA/jBTfhlHiIZFeb1f3i/d18P60xr4rAJlav4a49qDtcmZFpm8Tj3+hnn3AJAXGPdLSh3vyGU7E6G+XqtMPD21D0wTv8f+fcmoQzy8VoLMB7Y4dufxjBmaAETwulkxrXbsmPxautToJ4rqWGqjNcTiabTEqP121hrPdbMVf3sxIgnP3AWlFoxGPOLCIAvLCnY+jipiLE26Bvh++3v6o3jyFMeKmW5AKrvFYLFk32+LMrm18496dkqQfDDoj8i2rMKp+kFlW+tMO0o7Xf2qSfFisHWB1s2sv9m3tfFmxlYQM/UR4K5977zExcpSG4CB+bdsTmg9nWca5fh5x3R0M9pwFNDYB6IVj5DTAimeLBkvpuRIfUh8wkSV2NqFwiAO3hYSb9o+5PX7U5XgwgaECfLZd9Vg9zSpodhQY7BP0//AdyDN3wi 9IVirW++ 0qhRXb+XfgMTOeyVl0ZzFd4LHHOh8csJ0AHyv0v7GYPYNGnl8P3OklhurZAKxIcDmeLSk41m0QF0HqOxQhGgw95tmC94OztxFxdq7M5orv3An23hRcGEwMRj6NDe30dNG3JfZNd31lO2hDL95gCoYgOamykwmn1J8YHAikmPx5QkMLfmHZTxssN2UXTL+p2oZ86Maa3Ylxqw3QRu7UjsMspRavGxpLHk4rg5dEtKQqepL3ryfCIl7xSn15qWsWh/VU72Z20GHeJMqBKJnHmoPh26138gHGi8AB+An/R95QI11pOvq3eVOB8J+0psd9zVpwVRjlDtceSVGKEsj5zbSwzebAQpCVvxB2GXbTu7J3z3MYN6keadeLqcklbWku+iJwq5R9wBPuP9J0pEyUpQoR2xip/j/qgyn1du0ZqmMozJKbFraT6fytOR1X7Br7rfywDT3OOnmUU+kU047t7cb8zzMZPSkueEmWo/JxkwUsBEJEkcJUG8ZaE1fkE58+hFFWEgFSMQ9LkjrIvo4WYmkxQuLEgJ0d05m9K6rhULxFJyXIj0Dvav/vANdTLrAxG+cH1/w 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: * Mel Gorman wrote: > > 64 (BITS_PER_LONG) feels a bit small, especially on larger machines running > > threaded workloads, and the kmalloc of numab_state likely allocates a full > > cacheline anyway, so we could double the hash size from 8 bytes (2x1 longs) ^--- 16 bytes > > to 32 bytes (2x2 longs) with very little real cost, and still have a long > > field left to spare? > > > > You're right, we could and it's relatively cheap. I would worry that as > the storage overhead is per-VMA then workloads for large machines may > also have lots of VMAs that are not necessarily using threads. So I think there would be *zero* extra per-vma storage overhead, because vma->numab_state is a pointer, with the structure kmalloc() allocated, which should round the allocation to cacheline granularity anyway: 64 bytes on NUMA systems that matter. So with the current size of 'struct vma_numab_state' of 36 bytes, we can extend it by 16 bytes with zero additional storage cost. And since there's no cost, and less hash collisions are always good, the change wouldn't need any other justification. :-) [ Plus the resulting abstraction for the definition of a larger bitmask would probably make future extensions easier. ] But ... it was just a suggestion. Thanks, Ingo