Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp932558pxb; Tue, 14 Sep 2021 11:53:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz2arGGr6tOLh8udEoQduLQhvQBQt6bLFONiEDCiixhKKn7B5P/WgpO68jL9CoUqs2XoFkA X-Received: by 2002:a2e:a4db:: with SMTP id p27mr16580284ljm.161.1631645610624; Tue, 14 Sep 2021 11:53:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631645610; cv=none; d=google.com; s=arc-20160816; b=LaYtMhv43pkraCM2x0X/ndWIyLP5O1F5jj76DU/DeoXzAuBquL8guPHMLINeX7wKts EWmHkVepwrWwN6SwI3/BofgFAkEUvoRdygHHVxcGBl12ZveJzbK3SccnXSkYJsTFdpGO kJBgZ/YFzfsS6aM1+KhI53zzAMMtX8UhgW9K5jIlLXpSzjug5Ov/mZODcZ33KLGNxgQ9 QWe/KYDUV+LWWJJ4T5Oj0IiVsAuPe2IQGhQukt42iZ9db//vOtp+1J8mRWFe/U8nuMxE oq7bYw8iZRNxtsh82/HuAKOT3Ol9Uixekm4yy+0LOkw9l7kigRwmor1cKqvqPgh+V15W 1O5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=xgl8tmNVpP53cUFKld1Rt71FzleinQ+qnlvEYDZitJw=; b=j8nIgley0B8qxIF0WI/dA9PiaGoSPwOrQOQkJz1OCN0Xs9XWRmnXYUxUfEslCMF1kU QReY482TkbFhn3cykE0LKJXdVimQHRJ1/52EjFgkR3Rh4LwIXCrL67XM5IYkk6YBJnZn gBVaoICnHzyUGzDzggl1uE98i/kk2i+yiuqvY5R6URU5RYrlepqsySH3fiBwltuEZnHY 9BnxwJ7dBbrfE+xxMXni89V02KKX3WVb3o6gOqNrWdaoq0zuggPB1zPdgsHTlRlqIa78 S9CBqboxRTA30XwvfNP0BrkYDYsjvLiAhGl5hLANu2u4ihbHp7BJQ+2nO59bPZMHT7kd c0Lw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=DCOpZidw; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z27si2888790lfu.173.2021.09.14.11.53.02; Tue, 14 Sep 2021 11:53:30 -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=@google.com header.s=20210112 header.b=DCOpZidw; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229946AbhINSt7 (ORCPT + 99 others); Tue, 14 Sep 2021 14:49:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230008AbhINSt6 (ORCPT ); Tue, 14 Sep 2021 14:49:58 -0400 Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 86F0DC061762 for ; Tue, 14 Sep 2021 11:48:40 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id w4so361944ljh.13 for ; Tue, 14 Sep 2021 11:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xgl8tmNVpP53cUFKld1Rt71FzleinQ+qnlvEYDZitJw=; b=DCOpZidwA0rpIRjXO+o+QItCRB778ww1vOhhsZ1Sc03AZxzxl3siZADhctSGu9Isyp Vct8pMGe4BpjtbARjhj4XI0LGfhFpz7YuTXrqBAkrUXNIj/qb/XUMVdcbn2cS61p0oak ugZWNzntOh7bCMarRvhmI+owA+yEO0lvN3i0aC0slBPepI5Ox+BMbWHiEgNhniiQXrlR JegbaTPK4OvRAucDswQyXidzcNFjmhmNtiSDnkyQOpLkko3jpnUhkujSeNVO7HHcN72D N8e1xLGWzHf2nE6+Y6G3kz42sjz/jeJSH5AACOEM2hnv/hETq5zeqGGlPCwaSABbOBP6 UdcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xgl8tmNVpP53cUFKld1Rt71FzleinQ+qnlvEYDZitJw=; b=ODvNjDkQfGmmuidAv9AvzZxUVokx1JYMWJSZp70ySheDHCVFj9qY3hYPqDlu8asci0 d18EGf6oRjac3LP/e/dWnj/RMYabc87PGTPvps0pnJ+K75d+Ad2Kj1wsMHczK+85yAvP I+Wq7XZydH6/qtifwvuEVo9WEiUqFqdwnCT4Nwec6CXT+fJsGt/LD3Cq9gpYa/HiCIRL 3rpagjC8UjcOCffA8G794+XQwAaL25/UpiSHzLW/fKYDUe/ppVRK/mGh3o1RmuYoRHKh 9wcwmDh/qfy7BJ87G+/w1fi8D0uKJy6KO75G5IHJI0VSHtWkFhQTB5rPAFvkb1Eur2Pk 52ug== X-Gm-Message-State: AOAM531avnSjzGod332NebNTdodwsKeBwD5kVUNlhbYkCOQpHiSroJAZ hI7OkEtDSZj2vGyFtFeldICiTIEJlF6p+Gs42y8RPJNUAlQ= X-Received: by 2002:a2e:b44f:: with SMTP id o15mr17074256ljm.430.1631645318759; Tue, 14 Sep 2021 11:48:38 -0700 (PDT) MIME-Version: 1.0 References: <20210908184905.163787-1-posk@google.com> <20210908184905.163787-3-posk@google.com> In-Reply-To: From: Peter Oskolkov Date: Tue, 14 Sep 2021 11:48:27 -0700 Message-ID: Subject: Re: [PATCH 2/4 v0.5] sched/umcg: RFC: add userspace atomic helpers To: Peter Zijlstra Cc: Jann Horn , Peter Oskolkov , Ingo Molnar , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Paul Turner , Ben Segall , Andrei Vagin , Thierry Delisle Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 14, 2021 at 11:29 AM Peter Oskolkov wrote: > > On Tue, Sep 14, 2021 at 11:05 AM Peter Zijlstra wrote: > > > > On Tue, Sep 14, 2021 at 09:29:00AM -0700, Peter Oskolkov wrote: > > > In the version of the patchset that I'm preparing to send I've decided > > > to punt on the issue and just ask the userspace to deal with locking > > > the memory as it sees fit: mlock() is available and as far as I can > > > > Sadly mlock() does not imply no faults. Someone had a too literal > > reading of the POSIX-RT spec (of which mlock is part) and figured that > > all that was required was to keep the page in memory, not avoid faults. > > > > Linux has had this bahviour for ages, PREEMPT_RT has tried to change > > this, but so far to no avail. At some point sys_mpin() was proposed to > > meet the original POSIX-RT intent, but afaict that never actually > > happened. > > > > In short, mlock() does not avoid minor faults, or even migration faults, > > which can take a fair while to resolve. > > Ok, I'll go with transiently pinning pages in > __syscall_enter_from_user_work(), as you suggested. Seems easy enough > to do. Actually, I think pinning these pages when the worker exits to the userspace (i.e. is scheduled on a CPU) and releasing them when the worker is descheduled (blocks) would be better - this way we will be able to wake the server not only on blocking syscalls but also on pagefaults (on other pages) as well. Do you think this approach is acceptable? > > Thanks for the suggestion!