From nobody Fri Sep 02 14:26:16 2022 X-Original-To: freebsd-current@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 4MK0Zz1YKjz4Zk1c for ; Fri, 2 Sep 2022 14:26:19 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 4MK0Zy4ChCz3MRw for ; Fri, 2 Sep 2022 14:26:18 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-lj1-x234.google.com with SMTP id k22so2451143ljg.2 for ; Fri, 02 Sep 2022 07:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date; bh=DxFcGWSc57uGvKtL7PtpVKc75BnmyPT3uqftHh7jFeU=; b=gSWxxwUKMxlxTRgjCuOFzeGSOy7sgYyCMWw7QkXvZSmO0MjbyDKvFhlnRbAZjQEAPb cRmPD5d22UCiKCQcTRwYlS91mCPzzd90OizyjnEpyp/xbcmAMmSrkuc/UYGyT+0Isw3W tI2tRLYcZDPV315cr8QjCWRUro8Gb31eVq0yDzT54sX8r1d/2nvahU54TyzI3JDjz/SC pVHlVo4QdLBhzMg/vKJ7z2aeA/6r/FvNFYekywXJZmeYrhooJe6QFZO36wzXPp0f60UF s5TNEhURxKt/AzHkmCADsZwuC55bz/PBlZ3rDA0tImRaU7lAajumtQHaq+ttQCkh7m54 apuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=DxFcGWSc57uGvKtL7PtpVKc75BnmyPT3uqftHh7jFeU=; b=Dk7B3W180mSZNFrrPybqBZWZrcXKMx4QNEpn1LMtuu9nSiK26KonTmpB8SaQXXWWHc KbB44HOXfHlD+znAYE7SjrrISBv1XQzCv5uYUlefeQQBOg6MRKDs63NS3OjrIIKb/8cs hfMc9NCJptAbc33xtW1TCj2GjBWbTTJR+rt5AmKnLES+d5QIJEl24Ep5UhkF9R92GeNG 3Z7bT3Y5uKxp60uM3aFok2GQ+pVoKyNyVNWHgA1agkO7WFh6OLvnLeFDnTXdfSmJ8Yw1 fHJVb3e9vtI172A+qd1CSFmr1zIqs6TLpRRQltgCx17DB8EgK0ZLNFDgihk7iDjssmJq WeZQ== X-Gm-Message-State: ACgBeo37c2s0fuxMr0aC6fIclkQWgHX0rTHiGEwFzHnbIG+YrE8dJ1Uk bmldM6FV+97VKuCtekgEHRgjjYeqMbUs5aK0gAI= X-Google-Smtp-Source: AA6agR7Wdz1e+aiFbsbBiYgtVsPQfaBzr0wH1mMHb6ENPYdw57Nq5KvtlU7iY9zCMAYmiDPo04vTKVzIrkXYivwDqio= X-Received: by 2002:a2e:bc06:0:b0:266:23b7:283d with SMTP id b6-20020a2ebc06000000b0026623b7283dmr6711340ljf.151.1662128777044; Fri, 02 Sep 2022 07:26:17 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:6520:14d:b0:211:6cae:be17 with HTTP; Fri, 2 Sep 2022 07:26:16 -0700 (PDT) In-Reply-To: References: From: Mateusz Guzik Date: Fri, 2 Sep 2022 16:26:16 +0200 Message-ID: Subject: Re: kernel-side thread stack swapping To: Konstantin Belousov Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MK0Zy4ChCz3MRw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=gSWxxwUK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::234 as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-0.98)[-0.982]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::234:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_TO(0.00)[gmail.com]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 9/2/22, Konstantin Belousov wrote: > On Fri, Sep 02, 2022 at 04:11:40PM +0200, Mateusz Guzik wrote: >> On 9/2/22, Konstantin Belousov wrote: >> > On Fri, Sep 02, 2022 at 02:05:37PM +0200, Mateusz Guzik wrote: >> >> Is this really of practical use today? >> >> >> >> I have a WIP patch which needs to temporarily store something on the >> >> stack and should things go wrong enough it will be accessed by UMA, >> >> which can't handle the fault nor decide to skip the access. >> >> >> >> I can add something like td_pinstack or whatever to keep it around, >> >> but perhaps the entire machinery can be just whacked? >> > p_hold already does that. >> > >> >> I only need to protect the one stack and more importantly don't want >> to take the proc lock to bump p_hold (nor convert it to atomics), it's >> all thread-local so to speak. > > You do not want to take proc lock, or cannot? Note that only sleeping > thread' stack can be swapped out. > To add some context here I'm looking at reworking vnode batching in vdrop -> vdbatch_enqueue to remove vnode interlock -> vdbatch lock -> vnode list lock dependency (and improve scalability of the thing). Adding a proc lock here would negatively affect performance for everyone *and* weirdly serialize same-proc consumers. -- Mateusz Guzik