From nobody Thu Jan 13 20:32:20 2022 X-Original-To: dev-commits-src-all@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 49318195DD80; Thu, 13 Jan 2022 20:32:22 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JZbhQ1NqKz3DQ3; Thu, 13 Jan 2022 20:32:22 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qt1-x82e.google.com with SMTP id h15so4261088qtx.0; Thu, 13 Jan 2022 12:32:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=S5bLE67qWzIRkH2mCNYUwp/MjyGV3le15L1HMs2Zw/s=; b=P8eAUgu7PN8Pj32GMl44AQPAAA4OIsrJk4VGfpZ47kaD6Zz7RbsVWilKJbX0xQFk/J MyhsQ4yRr2WQgm+PN5UeyUjKaPl07vHNrwaE0h7xBFV1JsvJBYUiF+HqHFx4INRQyCNP LoJLCci6hAUxyB07hj3yii/qBBv+6eB9YiL06fJqPbq1hH8uhJU1hdSR19GvjB+8G+x+ WzkTc61dKbS+UD+L5LgWcaigERif2mF4dS2B6Zbn//SbBYBAQ8YvSk/nzVIX8AejuRhG Dy5KkIuIZ+7oTrpqYV4d0vMeiq9F5ggoyIlphqBhfgaBBuyEPvYygRiUZbiFfvedcstj 5xxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=S5bLE67qWzIRkH2mCNYUwp/MjyGV3le15L1HMs2Zw/s=; b=JjM0v8aLjYPS9/OdjRyc1bFHqlLxedNEOm1AUyO8b6HhA3jeNYVFL0Fi1BVTAtuLbC URRWigqLvTEZyyiE2pXZ1qvFOJX5pRvronCdHFq+0hRvTgyQgLOCKzBr+LzwJW7b4Ocv J5FMhJNAPf+2ftFs1DHUdnLdtPP35AgmaHNImH5p61VgRYFF6Bokqsp4rVEaZbyuXWvR e+MZbRzEeu6pH0Svle1IbOSi0s6k+mi6gFAIAV1fLJuI8VMsNhSMd4gI41YNcshBicKE OrTWoIzPkglqhFxknZhaoD0gte9JBY1kU3iIFdUd8/mP8PGr9gU5yjiH6vfVowjI4NEr +EBQ== X-Gm-Message-State: AOAM532dGKCYANxV7yF5bjL+7XRMJL/9XAPw2n54tBoTfaM0Y7KO4kDM nm5wncluTqKuGIsEwSl84SwKJD0WoTg= X-Google-Smtp-Source: ABdhPJydhk3Bs9nehg0kpoUPMbrxPfu+f7IcbPonKhH0AxbfgoC7+LVEGGwPwBR1L8kBtJPCuYwErQ== X-Received: by 2002:a05:622a:3ca:: with SMTP id k10mr5247309qtx.130.1642105941431; Thu, 13 Jan 2022 12:32:21 -0800 (PST) Received: from [10.231.1.66] ([38.32.73.2]) by smtp.gmail.com with ESMTPSA id p14sm2080842qtk.71.2022.01.13.12.32.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Jan 2022 12:32:20 -0800 (PST) Message-ID: <9ca0d02c-11f3-e95e-599e-ce9f7b4234c8@gmail.com> Date: Thu, 13 Jan 2022 15:32:20 -0500 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: git: ca2a7262df5e - main - Free UMA zones when a pass(4) instance goes away. Content-Language: en-US To: "Kenneth D. Merry" , Gleb Smirnoff Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202201131556.20DFud7f088871@gitrepo.freebsd.org> <20220113200013.GA53673@mithlond.kdm.org> From: Alexander Motin In-Reply-To: <20220113200013.GA53673@mithlond.kdm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JZbhQ1NqKz3DQ3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 13.01.2022 15:00, Kenneth D. Merry wrote: > On Thu, Jan 13, 2022 at 10:49:08 -0800, Gleb Smirnoff wrote: >> Kenneth, >> >> On Thu, Jan 13, 2022 at 03:56:39PM +0000, Kenneth D. Merry wrote: >> K> commit ca2a7262df5ec5fd07d4ac61738947f48c9cd7f2 >> K> Author: Kenneth D. Merry >> K> AuthorDate: 2022-01-13 15:50:40 +0000 >> K> Commit: Kenneth D. Merry >> K> CommitDate: 2022-01-13 15:54:56 +0000 >> K> >> K> Free UMA zones when a pass(4) instance goes away. >> K> >> K> If the UMA zones are not freed, we get warnings about re-using the >> K> sysctl variables associated with the UMA zones, and we're leaking >> K> the other memory associated with the zone structures. e.g.: >> K> >> K> sysctl_warn_reuse: can't re-use a leaf (vm.uma.pass44.size)! >> K> sysctl_warn_reuse: can't re-use a leaf (vm.uma.pass44.flags)! >> K> sysctl_warn_reuse: can't re-use a leaf (vm.uma.pass44.bucket_size)! >> K> sysctl_warn_reuse: can't re-use a leaf (vm.uma.pass44.bucket_size_max)! >> K> sysctl_warn_reuse: can't re-use a leaf (vm.uma.pass44.keg.name)! >> K> sysctl_warn_reuse: can't re-use a leaf (vm.uma.pass44.keg.rsize)! >> K> sysctl_warn_reuse: can't re-use a leaf (vm.uma.pass44.keg.ppera)! >> K> sysctl_warn_reuse: can't re-use a leaf (vm.uma.pass44.keg.ipers)! >> K> >> K> Also, correctly clear the PASS_FLAG_ZONE_INPROG flag in >> K> passcreatezone(). The way it was previously done, it would have >> K> had set the flag and cleared all other flags that were set at >> K> that point. >> >> Definitely not my area, but I wonder why would we create a zone per >> device? Why not a global zone in the driver? > > Good question. The primary reason is just that I didn't think about doing > it that way. Most everything else in the CAM peripheral drivers is done on > a per-instance basis. > > That said, having separate zones does make it a little easier/clearer to > track down memory leaks. The zones are created on the first call to > the CAMIOQUEUE ioctl for that instance. 99% of users won't have the zone > created, because they haven't used an application that would touch it. The > only application in the tree that uses it is camdd(8), when you use the > pass I/O method. > > BTW, the original reason for the asynchronous pass(4) interface was an > application at Spectra that sends SCSI passthrough commands to all of > the disks in a system (you could have hundreds or perhaps a thousand) > simultaneously. Rather than using an application thread per drive, or a > thread pool, this allows using one thread, and using kqueue(2)/kevent(2) > to get I/O completion notifications. > > We could change it to use a global zone for I/O requests and another for > request buffer memory, but I don't see a pressing reason to do it right > now. There is obviously no rush, but single zone for multiple devices would be much more efficient from per-CPU caches side on large SMP systems. -- Alexander Motin