Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp906342pxb; Tue, 14 Sep 2021 11:14:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw8oHskx6bHO00qh1o370McFPgcRBH1Mvdi3P5/FPxPzHSZHrvyRFaSkBqEjQ5tpAVeZ7dF X-Received: by 2002:a05:6e02:ecd:: with SMTP id i13mr13192792ilk.143.1631643273455; Tue, 14 Sep 2021 11:14:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631643273; cv=none; d=google.com; s=arc-20160816; b=07XicWx7RMiU7BBvws/HcuoI81oNSJzcSrAfz00/bOBe1cfxTZR0+DpzNW5NSZG11n 8uzivHGztsXQl/cI+MgcQO7BkID+B8wUVZwMNn83N/xEFKY+ymjWlK2/tHsiWELKJpDd CB1W9X+jwXvIPcKGr+7kuO1+3jeH508n2xdeSedeceOkB488mZ8KXz+AV2HN0fr9axqm f35G1e1lC0Ij7UeTfcZECnw+vMgXFpJXWn3hTahIDQughg3WuOEpr+2zCha1VTQtbebO furcTm/+J2aNyYJF0DIC8ihDjbCqLRmiHMUUT/wXppsybdhWd25K1VkF+SDU2AZ+lLgj 56tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=KD4Vc3vVXYvxW9rLdfJ2x8SJCDKSSlc572HoaFCtWLk=; b=hw31Y4GbxUO8Q7H4t7286YbRZSQw/tb3f/YBwfevayHxSpLM14gwrybzAf6fltsTIh dzxVHZOGx019m4uz1pdTz6qv9t1dg5BOCUZdxip+mahXl/e0xaM3gAULpNF+rGDWLvNI rcSfhpLHaxpfIBL4P1Y3m1qm9tgluX8U7i7EhgdhZpSxyOs5EZOqYEXWlz8w94y0APU7 MSgd7GipJ7ZmUlOPSZU5+AgHeIQiccTDxjGYGGVAEm31e52IUiuO6iNuYdmYSkEUr/9c /Z6Jmp2zLg91OY3WFe+3WHHIqCensj5PL2pg3jSXyiS19lP/tiI+oEgCo+OidiuaKltk gS+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=qrX2GCVb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o6si3174905jat.103.2021.09.14.11.14.20; Tue, 14 Sep 2021 11:14:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=qrX2GCVb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229464AbhINSOv (ORCPT + 99 others); Tue, 14 Sep 2021 14:14:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229870AbhINSOv (ORCPT ); Tue, 14 Sep 2021 14:14:51 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7CF19C061574; Tue, 14 Sep 2021 11:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=KD4Vc3vVXYvxW9rLdfJ2x8SJCDKSSlc572HoaFCtWLk=; b=qrX2GCVbRq7ZToTRh+/20Ru05J q/l2WtO5JPMI7uBwoMt6htPafTOFzO/jBypogN7qINpet0B1NzT4i+yZqC2/k2PRkT2C0bhq6yFhy D7QN+A7TcxAxmWc/6elEV4kVKCnHNsMqI+bTS5IdlIUHeZstwEWA7Tg1oUvPNBdniqf6AKIbnJw3z +71+RYhYPoUtxfuzD8jsgQ/BXYOwwL5S6mBapQQudVV5A7184UrZOR9tyg8OAe0TkCmsmKCQOZJHX hsvAqKotEspjmhhnL321T3xkrrIeasruzrIu6cY+WQEtwUgY+nj+Ubv0I9sMnlsrTO/x0KY/xYBOy eypov2nw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1mQCu0-00EwTG-Gg; Tue, 14 Sep 2021 18:11:40 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 49AFC3001C7; Tue, 14 Sep 2021 20:11:27 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 27FDB2D378DBA; Tue, 14 Sep 2021 20:11:27 +0200 (CEST) Date: Tue, 14 Sep 2021 20:11:27 +0200 From: Peter Zijlstra To: Andy Lutomirski Cc: Jann Horn , Peter Oskolkov , Peter Oskolkov , Ingo Molnar , Thomas Gleixner , Linux Kernel Mailing List , Linux API , Paul Turner , Ben Segall , Andrei Vagin , Thierry Delisle Subject: Re: [PATCH 2/4 v0.5] sched/umcg: RFC: add userspace atomic helpers Message-ID: References: <20210908184905.163787-1-posk@google.com> <20210908184905.163787-3-posk@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 14, 2021 at 09:52:08AM -0700, Andy Lutomirski wrote: > With a custom mapping, you don’t need to pin pages at all, I think. > As long as you can reconstruct the contents of the shared page and > you’re willing to do some slightly careful synchronization, you can > detect that the page is missing when you try to update it and skip the > update. The vm_ops->fault handler can repopulate the page the next > time it’s accessed. The point is that the moment we know we need to do this user-poke, is schedule(), which could be called while holding mmap_sem (it being a preemptable lock). Which means we cannot go and do faults. > All that being said, I feel like I’m missing something. The point of > this is to send what the old M:N folks called “scheduler activations”, > right? Wouldn’t it be more efficient to explicitly wake something > blockable/pollable and write the message into a more efficient data > structure? Polling one page per task from userspace seems like it > will have inherently high latency due to the polling interval and will > also have very poor locality. Or am I missing something? The idea was to link the user structures together in a (single) linked list. The server structure gets a list of all the blocked tasks. This avoids having to a full N iteration (like Java, they're talking stupid number of N). Polling should not happen, once we run out of runnable tasks, the server task gets ran again and it can instantly pick up all the blocked notifications.