From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78E76C33CAF for ; Thu, 23 Jan 2020 08:19:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4FAB524684 for ; Thu, 23 Jan 2020 08:19:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="FoZFuOpI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726968AbgAWITf (ORCPT ); Thu, 23 Jan 2020 03:19:35 -0500 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:40115 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725785AbgAWITf (ORCPT ); Thu, 23 Jan 2020 03:19:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579767574; 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: in-reply-to:in-reply-to:references:references; bh=r8G9CiUcTrvaUADmAjAIB3KCKMVrK5hIYghUAfanm1s=; b=FoZFuOpIBG+mw4dSFEXvDtg/itXuFJfoMRiAySH74ydGir4rNFSGmGyiqAc07VWfY2Vf88 nTOBsZtWqWBvbx3chaDz+QzZo9UHXzNTBs4lPkEtJa5/E15aIv2wwlJpAT5LXMjh+SR6O8 lWA0NC3Z/HCtSklwh2gCm/q+yGeVTS8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-161-GDK3HAbMObCnYJNP01EYcQ-1; Thu, 23 Jan 2020 03:19:30 -0500 X-MC-Unique: GDK3HAbMObCnYJNP01EYcQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0034A1800D48; Thu, 23 Jan 2020 08:19:27 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-116-150.ams2.redhat.com [10.36.116.150]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B137581C0A; Thu, 23 Jan 2020 08:19:20 +0000 (UTC) From: Florian Weimer To: "H. Peter Anvin" Cc: Mathieu Desnoyers , Chris Lameter , Jann Horn , Peter Zijlstra , Thomas Gleixner , linux-kernel , Joel Fernandes , Ingo Molnar , Catalin Marinas , Dave Watson , Will Deacon , shuah , Andi Kleen , linux-kselftest , Russell King , Michael Kerrisk , Paul , Paul Turner , Boqun Feng , Josh Triplett , rostedt , Ben Maurer , linux-api , Andy Lutomirski Subject: Re: [RFC PATCH v1] pin_on_cpu: Introduce thread CPU pinning system call References: <20200121160312.26545-1-mathieu.desnoyers@efficios.com> <430172781.596271.1579636021412.JavaMail.zimbra@efficios.com> <2049164886.596497.1579641536619.JavaMail.zimbra@efficios.com> <1648013936.596672.1579655468604.JavaMail.zimbra@efficios.com> Date: Thu, 23 Jan 2020 09:19:18 +0100 In-Reply-To: (H. Peter Anvin's message of "Wed, 22 Jan 2020 23:53:54 -0800") Message-ID: <87a76efuux.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Sender: linux-kselftest-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org * H. Peter Anvin: > On 2020-01-21 17:11, Mathieu Desnoyers wrote: >> ----- On Jan 21, 2020, at 4:44 PM, Chris Lameter cl@linux.com wrote: >> >>> These scenarios are all pretty complex and will be difficult to understand >>> for the user of these APIs. >>> >>> I think the easiest solution (and most comprehensible) is for the user >>> space process that does per cpu operations to get some sort of signal. If >>> its not able to handle that then terminate it. The code makes a basic >>> assumption after all that the process is running on a specific cpu. If >>> this is no longer the case then its better to abort if the process cannot >>> handle moving to a different processor. >> >> The point of pin_on_cpu() is to allow threads to access per-cpu data >> structures belonging to a given CPU even if they cannot run on that >> CPU (because it is offline). >> >> I am not sure what scenario your signal delivery proposal aims to cover. >> >> Just to try to put this into the context of a specific scenario to see >> if I understand your point, is the following what you have in mind ? >> >> 1. Thread A issues pin_on_cpu(5), >> 2. Thread B issues sched_setaffinity removing cpu 5 from thread A's >> affinity mask, >> 3. Noticing that it would generate an invalid combination, rather than >> failing sched_setaffinity, it would send a SIGSEGV (or other) signal >> to thread A. >> >> Or so you have something entirely different in mind ? >> > > I would agree that this seems like the only sane option, or you will > be in a world of hurt because of conflicting semantics. It is not just > offlining, but what happens if a policy manager calls > sched_setaffinity() on another thread -- and now the universe breaks > because a library is updated to use this new system call which > collides with the expectations of the policy manager. Yes, this new interface seems fundamentally incompatible with how affinity masks are changed today. Would it be possible to make pin_on_cpu_set to use fallback synchronization via a futex if the CPU cannot be acquired by running on it? The rseq section would need to check the futex as well, but would not have to acquire it. Thanks, Florian