From owner-dev-commits-src-all@freebsd.org Fri Mar 12 13:15:24 2021 Return-Path: Delivered-To: dev-commits-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 54163578AD9; Fri, 12 Mar 2021 13:15:24 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 4DxmWw1Gq6z3psq; Fri, 12 Mar 2021 13:15:23 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 78A95260783; Fri, 12 Mar 2021 14:15:21 +0100 (CET) Subject: Re: git: d1cbe7908986 - main - Allocating the LinuxKPI current structure from an interrupt thread must be done using the M_NOWAIT flag after 1ae20f7c70ea . To: Konstantin Belousov Cc: John Baldwin , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202103100952.12A9qRKR040117@gitrepo.freebsd.org> <2b1739ab-000c-ca28-5a59-0a3e19ef4591@selasky.org> <5aaa5f2a-a67d-a495-7f56-a6b31c2494c7@FreeBSD.org> <3dcd63b0-fe90-2855-f349-2117ca4b6b26@selasky.org> <8fe37b5e-29a7-ffeb-fddb-3b31a6e79ab0@selasky.org> From: Hans Petter Selasky Message-ID: Date: Fri, 12 Mar 2021 14:15:02 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DxmWw1Gq6z3psq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: dev-commits-src-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the src repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 13:15:24 -0000 Hi, On 3/12/21 1:00 PM, Konstantin Belousov wrote: > On Thu, Mar 11, 2021 at 08:20:05PM +0100, Hans Petter Selasky wrote: ... > And how this would change? The linux_set_current() calls are spread all > over the linuxkpi code, so > - you cannot eliminate them for interrupt thread context Regular interrupt threads typically don't use the "current" or "task structure" at all. > - they are already there anyway. For user-space, yes. > What is your point? I still believe an own UMA zone is overkill for the purpose of task_struct . We could just pre-allocate these structures into a linked list, and dequeue these for interrupt threads only. Every time a new interrupt is allocated we allocate one more of these structures beforehand, and then we use that structure back when the ITHREAD flags is set in the thread structure, similar to what you are doing, except we don't use UMA zones. >> >>> >>>> >>>> Also I don't see why we need to create a own UMA zone for these simple >>>> structures. Won't the per-CPU sysctl consume more memory than the actual >>>> task structures being allocated? >>> Dedicated UMA zone allows to gracefully solve the requirement of non-failing >>> allocation in non-sleepable context. This is much simpler and cleaner than >>> either trying to enumerate all existing ithreads or adding consumer-specific >>> controls into generic kernel facility. >>> >> >> Maybe I'm new to UMA zones. The M_USE_RESERVE can also be used with malloc() >> ? > Yes M_USE_RESERVE can be used on zones without reserve (like malloc zones), > but it would have a different meaning. On allocation failure due to low > memory, for zones with reserve, it means: > - first look at reserve, and if nothing left, you are allowed to consume > the last free page in the system > For zones without reserve, it just allows to utilize the last free page. > In other words, if you have a reserve in zone, alloc requests are guaranteed > to not fail regardless of the free memory. OK. --HPS