From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-0.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_GREY autolearn=ham autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [IPv6:2a01:4f8:1c0c:6b10::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 69D661F542 for ; Thu, 25 May 2023 02:08:04 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=KXj9SLbi; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=sendgrid.net header.i=@sendgrid.net header.a=rsa-sha256 header.s=smtpapi header.b=c/CEFRdg; dkim-atps=neutral Received: from nue.mailmanlists.eu (localhost [127.0.0.1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 118E77E6E9; Thu, 25 May 2023 02:07:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1684980476; bh=IHlHaEO6gTaUYIdXp4RKjApk4ovtQw8zsQkOr4JA1fo=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=KXj9SLbiT1xfYQbbHNp3vLkw2AnGAL9wa8Y8NOV7446Gc/N6QC9wy7LL7XbZ2LlLa 3Tk9YDlm+pTYbhILfPiTUXisM9pqe/1VQOrUEn/fcG719b2BhceFlcrmiueH1CoCTc qw+S11lco1AaEalitPxZ5fGtp6mp7E/lHCRVxYKY= Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by nue.mailmanlists.eu (Postfix) with ESMTPS id BF8D87E661 for ; Thu, 25 May 2023 02:07:52 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (1024-bit key; unprotected) header.d=sendgrid.net header.i=@sendgrid.net header.a=rsa-sha256 header.s=smtpapi header.b=c/CEFRdg; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sendgrid.net; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=smtpapi; bh=o8pz8vfdclghWp/EBMsZm1IeMQaYLTkljhtiKkiB6ss=; b=c/CEFRdgT2czCMQMds3G9ImZDzH1CILCUayc4V+u1RDeAyxpbOZ75PArwG9VEpwwTuhl tngscjVxR++yUE3ATCoRgqqsgE+FgXxzPrGcTYg0md/nUVOA56ZP17tOqftsG4F5K4tp1b PdnwtuzosPxymZQ/nGIl9enCxXf72TkhQ= Received: by filterdrecv-65f68489c8-zw5h4 with SMTP id filterdrecv-65f68489c8-zw5h4-1-646EC2F6-27 2023-05-25 02:07:50.809228606 +0000 UTC m=+1218695.228138350 Received: from herokuapp.com (unknown) by geopod-ismtpd-15 (SG) with ESMTP id GvQYouUaQQOJ68Szo8ZdQQ for ; Thu, 25 May 2023 02:07:50.737 +0000 (UTC) Date: Thu, 25 May 2023 02:07:50 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Misc X-Redmine-Issue-Id: 19122 X-Redmine-Issue-Author: smcgivern X-Redmine-Issue-Assignee: ioquatix X-Redmine-Sender: ioquatix X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-Redmine-MailingListIntegration-Message-Ids: 90118 X-SG-EID: =?us-ascii?Q?RXGrw3WrKfUduNFRrzMMcXYHKEABJI9T84jNjq2g6rDyVZVrVmLnDcWmdSCkDw?= =?us-ascii?Q?+p8WgAmp7jJCn8oj7Ku6pocxRS6TfdMNjig618v?= =?us-ascii?Q?evVxAhBr063rpJuBQhxNP32fz93olkWgdKdbfrZ?= =?us-ascii?Q?cjT=2FMOPfmr594nBtSzmFokHfYWIKN8Vz=2FqS2xCR?= =?us-ascii?Q?eCPJLKCIgphSgrYV6GUYsQd=2FbXdHakZ27k7Isnr?= =?us-ascii?Q?ZH1FncnocQhgCNGyGdzz=2FtM680DYoakakvSYYWL?= =?us-ascii?Q?Oh2k+KIJE0FOuQ3uGrN=2Fkqfz5w8AMYDAnkGxai6?= =?us-ascii?Q?qiU=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== Message-ID-Hash: 5X7FJJ7NIDXFLNIJ24LLHPZ5H6F5K4MT X-Message-ID-Hash: 5X7FJJ7NIDXFLNIJ24LLHPZ5H6F5K4MT X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@sendgrid.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.3 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:113652] [Ruby master Misc#19122] Use MADV_DONTNEED instead of MADV_FREE when freeing a Fiber's stack List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "ioquatix (Samuel Williams) via ruby-core" Cc: "ioquatix (Samuel Williams)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #19122 has been updated by ioquatix (Samuel Williams). If you want to use a specific mode (OS specific), you can do this: On Linux, find the mode, e.g. `MADV_DONTNEED = 6` (https://github.com/torvalds/linux/blob/933174ae28ba72ab8de5b35cb7c98fc211235096/arch/alpha/include/uapi/asm/mman.h#L50). Shift it one bit to the left (i.e. multiply by 2) `= 12`. Then run Ruby like this: ``` > RUBY_SHARED_FIBER_POOL_FREE_STACKS=12 ruby ``` This will force the use of `MADV_DONTNEED`. However, no validation is done, so the OS may not accept it. So it will also emit a warning that this behaviour is OS dependent and may crash your Ruby interpreter. With this in place, you should be able to test your code. As for making this the default, I suppose we could consider it but we'd need to confirm the performance impact. ---------------------------------------- Misc #19122: Use MADV_DONTNEED instead of MADV_FREE when freeing a Fiber's stack https://bugs.ruby-lang.org/issues/19122#change-103295 * Author: smcgivern (Sean McGivern) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- I'd like to propose that Ruby stops using MADV_FREE when freeing a Fiber's stack, and switches to using MADV_DONTNEED even when MADV_FREE is supported. MADV_FREE is used in one place in the Ruby codebase, when freeing the stack of a freed Fiber: https://git.ruby-lang.org/ruby.git/tree/cont.c#n683 The comment for `fiber_pool_stack_free` says: ```c // We advise the operating system that the stack memory pages are no longer being used. // This introduce some performance overhead but allows system to relaim memory when there is pressure. ``` Where possible (i.e. on Linux 4.5 and later), `fiber_pool_stack_free` uses `MADV_FREE` over `MADV_DONTNEED`. This has the side effect that memory statistics such as RSS will not reduce until and unless the OS actually reclaims that memory. If that doesn't happen, then the reported memory usage via RSS will be much higher than the 'real' memory usage. If this was pervasive throughtout the Ruby codebase then that would be one thing, but currently this is just for Fiber. This means that: 1. A program that doesn't use Fiber will have somewhat reliable RSS statistics on recent Linux. 2. A program that heavily uses Fiber (such as something using Async::HTTP) will see an inflated RSS statistic. Go made a similar change to the one I'm proposing here for similar reasons: https://github.com/golang/go/issues/42330 > While `MADV_FREE` is somewhat faster than `MADV_DONTNEED`, it doesn't affect many of the statistics that `MADV_DONTNEED` does until the memory is actually reclaimed. This generally leads to poor user experience, like confusing stats in `top` and other monitoring tools; and bad integration with management systems that respond to memory usage. > [...] > I propose we change the default to prefer `MADV_DONTNEED` over `MADV_FREE`, to favor user-friendliness and minimal surprise over performance. I think it's become clear that Linux's implementation of `MADV_FREE` ultimately doesn't meet our needs. As an aside, MADV_FREE was not used in Ruby 3.1 (https://bugs.ruby-lang.org/issues/19101), and I haven't found any bugs filed about this behaviour other than that one. -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/