From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com [IPv6:2001:4860:4864:20::35]) by sourceware.org (Postfix) with ESMTPS id 7278B3858D1E for ; Wed, 17 May 2023 13:20:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7278B3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-1929818d7faso10982260fac.0 for ; Wed, 17 May 2023 06:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1684329649; x=1686921649; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=e/ybRgiJeQIR2APKEyQUGccAX8n/PhDpXIeSMz4T0yg=; b=KhML+SOaHCKsMgIGSG5PHtujsfrGX5N0xod5Pipq6VPOtJ5zRyA6xdaEZh4KbyKJD1 1sRDs0iTcLvaistaZkB5mrAX1p/J6+iwfyau3S9+R7DtkwYCyoy07tl3h330B0xxz3gg oIx3i6le09R+yvtMzoxaFfRKvvXB1mtSNyj3jYvJsyuoSjDja39MY1tnUTw751dEpall 62Gmm2sR1fpvTzCgGCPAXJ40EWfbbyt7bYxyxpqeXBY8+GwuQabCAYEm79IZ+9HztCgp V2/n54GEMm1rpfLVBRbSw23U3dfiRnUne7smXRQTVc8aASQEXKiq80ECPr0duNQmkoGj v1Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684329649; x=1686921649; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=e/ybRgiJeQIR2APKEyQUGccAX8n/PhDpXIeSMz4T0yg=; b=RynjrQJ5C9B7xZSzPMqoKNOF4/tirfWOk9Vzw1zw6vNZJ9YaWFjEYeNe2kiL9icWte Q9hZ77YTs45dd9ysrMiS9RJtHOQRlJ1Ils12n0m7btqUYu6ljn2HSQ2NcO4oDo/APPbz 8oaeXK4eL0A6s1gH7wWils7GvqcdLp0ZYVmMu+8UqY59lu+MzKYsPGYM/xFaQNnodmXM IpD/pbZkoe+XqdhV6HWGfSPgPsMkmAXIuJz6TXbfiLo2C6FOKBEYuvXKGQTQAUBLgQu8 5/vHsO1v+sxRPdYDs6fRHTxtO1aFiUo5umwdazQc8qNKY30eumfCWbx9AULt01X/ue30 7pSg== X-Gm-Message-State: AC+VfDybVIuLWMPr6YFBSpF6D3rxOsUhozITKtjPJwAySyVC+lAJ5z5e 43hMBMI3838d1K91Ljw1x7N/RbOJgV2Q6PeW2HFYIA== X-Google-Smtp-Source: ACHHUZ4USx3e8RA/lJBmzV6rzgbGMkNF5eB02E7pGnmwlbwOOpWL/aP6s777amD9FkPU7NKjqEapgg== X-Received: by 2002:a9d:7203:0:b0:6ad:f3fc:ba74 with SMTP id u3-20020a9d7203000000b006adf3fcba74mr1003040otj.16.1684329649541; Wed, 17 May 2023 06:20:49 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:c914:a525:210b:3f9e:9366? ([2804:1b3:a7c0:c914:a525:210b:3f9e:9366]) by smtp.gmail.com with ESMTPSA id a6-20020a056830008600b006adbf08a7d2sm3587009oto.53.2023.05.17.06.20.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 May 2023 06:20:48 -0700 (PDT) Message-ID: <967b94b4-d819-278f-1782-6b758d0841b6@linaro.org> Date: Wed, 17 May 2023 10:20:46 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH] nptl: Disable THP on thread stack if it incurs in large RSS usage Content-Language: en-US To: Wilco Dijkstra , "libc-alpha@sourceware.org" , Cupertino Miranda References: <20230420172436.2013698-1-adhemerval.zanella@linaro.org> <4115d7fd-d7a7-cdb1-3833-daf45186480f@linaro.org> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 17/05/23 09:49, Wilco Dijkstra wrote: > Hi Adhemerval, > >>> The question is, under what circumstances are huge pages in stacks beneficial and >>> in which cases are they not? If have a good answer to that, then we can automatically >>> do the right thing without needing a tuning. >>> >> >> Afaiu the issue is not whether huge page in stacks is beneficial, but rather >> when kernel will fall back to default pages anyway which will be just waste >> cycles.  Another option would be tune the default stack and guard size >> to avoid this issue, but this might require some more heuristics to find a >> good spot to avoid too much VMA waste. > > The kernel won't fallback to standard pages - like I said, it really allocates a huge > page when it can (based on alignment of the stack) and that is what causes the > increase of RSS size. But that's not evidence of an issue. AFAIU the issue is after the stack is allocated with huge pages, the kernel needs to fallback to standard pages because the guard 'page' will be also within the same huge page allocated for the stack. My understanding is, once kernel needs to fallback to use default pages, it allocates *all* the large page range. This is what the RSS increase make me believe, I am not sure if there is technical limitation to just making the range COW (since at the time of guard protection setup, no the page has not been touched yet). > > So the real question is when do huge pages make sense for stacks? But that's not what the patch is trying to do, it only tries tot mitigate a specific corner case where THP will be ineffective. I agree with Cupertino that this question is really hard to answer and it will be really depended of the workload and/or runtime characteristics that we will need to plug in kernel feedback to have some answer.