From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D18A714B075 for ; Fri, 29 Nov 2024 16:40:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732898446; cv=none; b=XwSP5QU0DDkeLWfJpfzElUgXis90RHNvX2mJWze/qZAhh+oIEn4E1mCHdFL4GbCirZ8GeDuoDpHYyYNnWhoFDNy9TCFIgO3ROj05zisLk+aPVrKFzcsL6teGI7+7rIHQCfdvljW5die/mu/erD93Ns3LSYSdqmdeZnQtlftcuHo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732898446; c=relaxed/simple; bh=az39fDf+MhRZMw9gFTdPNqw5XUR3nQ20B8N3wHXK3SY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=ub2B9/fUim6y7TZDsoCT/Fkxmf4XRdqaIf+AEhlI+hh2do9Y5ptubN+RFwQG8VX60HVAj8S0ikxtLgC8elWx2/UwC9uHRkQWIJo8i9iaV9dBWVAZWjcNPzFuDGK0HIEjslES+Mq2sabTbx1M8dxR8RyLGmkti+dz/fKfF7wse5A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=HLcHSN0f; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="HLcHSN0f" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1732898443; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2oxQ2EopQjYunks2eIxH2qb+BPEjEvokj+yvCZveiP0=; b=HLcHSN0fqRsvoYLqKz7fg/gLlrP6cRc2KBHRkF3VNk7yE75efKv4ol64zvgZmSAvYUfjgG ALaA2Gf5rIs0wNHGD4Nj/70UF3QZwf9RzM0UkamRTQ7fpwFup/ck7sQOGIc4VzBUooSFqo YtmaaA5wkUzhdGK3Dh+vPfhOUTviWSM= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-9-ikY3J6PgNYmTDvipL3MjuQ-1; Fri, 29 Nov 2024 11:40:42 -0500 X-MC-Unique: ikY3J6PgNYmTDvipL3MjuQ-1 X-Mimecast-MFC-AGG-ID: ikY3J6PgNYmTDvipL3MjuQ Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-6d884999693so11569706d6.0 for ; Fri, 29 Nov 2024 08:40:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732898442; x=1733503242; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2oxQ2EopQjYunks2eIxH2qb+BPEjEvokj+yvCZveiP0=; b=j69DL0+6srAUXSvA46ai4elMMdgfYItOUpFmO421ALOYUJRqWL/bJEdqgKHtGlb76n HQOLMN0k+E5M7lB3yPPTgg9URG4pVacGPIgqUndDLP+0yNFaRpzlG6xDvOqye2UiPrWz P7w7ULmvY0WBrHPs8XbU58fPDkqKFN/d2n1wHRw+iWJfDflewZ1kT1LvJ/NtTkAFuCvo Yv1kEti+rC7Zah3tfWxMZjwlLdd4US/PYccd8cgEksbZ6vZGp2al04ymXgScjkRqYwIu uZJDnY/tyPn0wYLHErIkq5HhJXS0BRyPvkpRFf1FAXfcXU8YqMt/3bOaC10ycInOMlOx UaIA== X-Forwarded-Encrypted: i=1; AJvYcCWOdH4m1wMPagAu6dj9xbJWDRCWoo84l0+ZmmuVL9awxJIHY7QPQ0Qy+gzF7oVrd4yro4CENmgMmmY=@vger.kernel.org X-Gm-Message-State: AOJu0Yy4tLMuO/1tnyaNTEZgg06YQQ6R5XskJiVcvBvnocNUoMq33+r3 06NmglAplvNLkPWem7mlguZa3gcuvZwxWED8SWytSIAZ/I4EovPUCnwZnlxLcYhzixInFNuGzOb b93OmPTeeCvYCabnPm+H7Kqp/LuIBmGJKmC+HAXX9LgaXWm2K7GzX7w/RIg== X-Gm-Gg: ASbGnctV3j2983Vtp3FCIqFzpg1XRZhlzY68Y0x0+DhczXXA3fhgB//nSHk+J/8FHsS J4Y8Msr8XmnrpeTYIeSMVLBUp55pABQ5/MOGNt6s4/wb4bQxlocs972d9JFFtW+4PplGdvZUu/Q kTXug7sdzkoeyJHoaRsMSFvBXDLwGqLfkjB97V/xRHMOWJdY19zVFruuK/XgxfD2B97+ti835hk xRSWz1msCAIUzH45UGt53cRIJKDBtI3o+s/nrmmw7opeZsK6I4nOgIkNsEswqdeAUOz4YLTXfLk i0uwv/KEj3wYa4upXEeKCwkbRZBMzUW19R8= X-Received: by 2002:a05:6214:c62:b0:6d4:1a99:427b with SMTP id 6a1803df08f44-6d864d8e4famr151983756d6.30.1732898442040; Fri, 29 Nov 2024 08:40:42 -0800 (PST) X-Google-Smtp-Source: AGHT+IG9RcRtBRvnIDfzr2/iRL96o9fRk4J92A47PIoCtseLUfNoii93tfgZQ/3Nm/m06TGA/XDcKA== X-Received: by 2002:a05:6214:c62:b0:6d4:1a99:427b with SMTP id 6a1803df08f44-6d864d8e4famr151982836d6.30.1732898441562; Fri, 29 Nov 2024 08:40:41 -0800 (PST) Received: from vschneid-thinkpadt14sgen2i.remote.csb (213-44-141-166.abo.bbox.fr. [213.44.141.166]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6d8752064besm18111326d6.71.2024.11.29.08.40.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Nov 2024 08:40:40 -0800 (PST) From: Valentin Schneider To: Frederic Weisbecker Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, bpf@vger.kernel.org, x86@kernel.org, rcu@vger.kernel.org, linux-kselftest@vger.kernel.org, Nicolas Saenz Julienne , Steven Rostedt , Masami Hiramatsu , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Paolo Bonzini , Wanpeng Li , Vitaly Kuznetsov , Andy Lutomirski , Peter Zijlstra , "Paul E. McKenney" , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Boqun Feng , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Josh Poimboeuf , Jason Baron , Kees Cook , Sami Tolvanen , Ard Biesheuvel , Nicholas Piggin , Juerg Haefliger , Nicolas Saenz Julienne , "Kirill A. Shutemov" , Nadav Amit , Dan Carpenter , Chuang Wang , Yang Jihong , Petr Mladek , "Jason A. Donenfeld" , Song Liu , Julian Pidancet , Tom Lendacky , Dionna Glaze , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , Juri Lelli , Marcelo Tosatti , Yair Podemsky , Daniel Wagner , Petr Tesarik Subject: Re: [RFC PATCH v3 11/15] context-tracking: Introduce work deferral infrastructure In-Reply-To: References: <20241119153502.41361-1-vschneid@redhat.com> <20241119153502.41361-12-vschneid@redhat.com> Date: Fri, 29 Nov 2024 17:40:29 +0100 Message-ID: Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 24/11/24 22:46, Frederic Weisbecker wrote: > Le Fri, Nov 22, 2024 at 03:56:59PM +0100, Valentin Schneider a =C3=A9crit= : >> On 20/11/24 18:30, Frederic Weisbecker wrote: >> > Le Wed, Nov 20, 2024 at 06:10:43PM +0100, Valentin Schneider a =C3=A9c= rit : >> >> On 20/11/24 15:23, Frederic Weisbecker wrote: >> >> >> >> > Ah but there is CT_STATE_GUEST and I see the last patch also applie= s that to >> >> > CT_STATE_IDLE. >> >> > >> >> > So that could be: >> >> > >> >> > bool ct_set_cpu_work(unsigned int cpu, unsigned int work) >> >> > { >> >> > struct context_tracking *ct =3D per_cpu_ptr(&context_tracking, c= pu); >> >> > unsigned int old; >> >> > bool ret =3D false; >> >> > >> >> > preempt_disable(); >> >> > >> >> > old =3D atomic_read(&ct->state); >> >> > >> >> > /* CT_STATE_IDLE can be added to last patch here */ >> >> > if (!(old & (CT_STATE_USER | CT_STATE_GUEST))) { >> >> > old &=3D ~CT_STATE_MASK; >> >> > old |=3D CT_STATE_USER; >> >> > } >> >> >> >> Hmph, so that lets us leverage the cmpxchg for a !CT_STATE_KERNEL che= ck, >> >> but we get an extra loop if the target CPU exits kernelspace not to >> >> userspace (e.g. vcpu or idle) in the meantime - not great, not terrib= le. >> > >> > The thing is, what you read with atomic_read() should be close to real= ity. >> > If it already is !=3D CT_STATE_KERNEL then you're good (minus racy cha= nges). >> > If it is CT_STATE_KERNEL then you still must do a failing cmpxchg() in= any case, >> > at least to make sure you didn't miss a context tracking change. So th= e best >> > you can do is a bet. >> > >> >> >> >> At the cost of one extra bit for the CT_STATE area, with CT_STATE_KER= NEL=3D1 >> >> we could do: >> >> >> >> old =3D atomic_read(&ct->state); >> >> old &=3D ~CT_STATE_KERNEL; >> > >> > And perhaps also old |=3D CT_STATE_IDLE (I'm seeing the last patch now= ), >> > so you at least get a chance of making it right (only ~CT_STATE_KERNEL >> > will always fail) and CPUs usually spend most of their time idle. >> > >>=20 >> I'm thinking with: >>=20 >> CT_STATE_IDLE =3D 0, >> CT_STATE_USER =3D 1, >> CT_STATE_GUEST =3D 2, >> CT_STATE_KERNEL =3D 4, /* Keep that as a standalone bit */ > > Right! > >>=20 >> we can stick with old &=3D ~CT_STATE_KERNEL; and that'll let the cmpxchg >> succeed for any of IDLE/USER/GUEST. > > Sure but if (old & CT_STATE_KERNEL), cmpxchg() will consistently fail. > But you can make a bet that it has switched to CT_STATE_IDLE between > the atomic_read() and the first atomic_cmpxchg(). This way you still have > a tiny chance to succeed. > > That is: > > old =3D atomic_read(&ct->state); > if (old & CT_STATE_KERNEl) > old |=3D CT_STATE_IDLE; > old &=3D ~CT_STATE_KERNEL; > > > do { > atomic_try_cmpxchg(...) > > Hmm? But it could equally be CT_STATE_{USER, GUEST}, right? That is, if we have all of this enabled them we assume the isolated CPUs spend the least amount of time in the kernel, if they don't we get to blame the user.