From nobody Tue Jun 04 21:28:49 2024 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Vv3cn6fhTz5MclW for ; Tue, 04 Jun 2024 21:28:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vv3cn2MZHz4t6t; Tue, 4 Jun 2024 21:28:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 454LSnqT030417; Wed, 5 Jun 2024 00:28:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 454LSnqT030417 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 454LSnEe030416; Wed, 5 Jun 2024 00:28:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 5 Jun 2024 00:28:49 +0300 From: Konstantin Belousov To: Poul-Henning Kamp Cc: John Baldwin , Mark Johnston , freebsd-arch@freebsd.org Subject: Re: removing support for kernel stack swapping Message-ID: References: <6ddedba5-fc2f-4caa-aab5-bd29ca4fdf0b@FreeBSD.org> <202406042043.454Kh2ls009155@critter.freebsd.dk> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202406042043.454Kh2ls009155@critter.freebsd.dk> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4Vv3cn2MZHz4t6t On Tue, Jun 04, 2024 at 08:43:02PM +0000, Poul-Henning Kamp wrote: > Konstantin Belousov writes: > > > Similarly, it is not easy to shrink the vnode cache in case of memory > > shortage, due to need to free the owned pages, and most likely before > > that, free the owned buffers which otherwise wire the pages. > > Also we need to flush namecache before a vnode can be freed, which is > > somewhat unfortunate. > > Many years ago I asked the then VM-wizards if we could have a global > kernel integer variable with a "VM-state-of-the-system" so caches > could modulate their behavior. > > Having something as simple as: > > 0 - free pizza > 1 - dont make it worse I believe this is same as vm_page_count_severe() > 2 - please help and this one is vm_page_count_min() > > would enable most of the caches in the kernel pull the right direction > before things get too critical. Filesystems, at least the kind that uses the buffer cache, tend to avoid creating delayed writes if we are in the state "1". This does not help with shrinking the existing cached dormant objects. Also note that state "2" is not too useful to report to userspace, because most syscalls and page faults requiring a page allocation going to block at that moment.