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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 17FC3C433EF for ; Tue, 14 Sep 2021 18:48:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0165A61130 for ; Tue, 14 Sep 2021 18:48:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231593AbhINSuC (ORCPT ); Tue, 14 Sep 2021 14:50:02 -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-Google-Smtp-Source: ABdhPJzOeKRQ0bjI+2VVj2I8hJUcksi5JTS5V9qKCoohUYlJtpmSDZBaVU6Yla/J7LqeyarQ8+6F1+kQ5PwxFXeTvkM= 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!