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=-2.2 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 95346C433E0 for ; Fri, 19 Jun 2020 14:00:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 55CC2207FC for ; Fri, 19 Jun 2020 14:00:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=kernel-dk.20150623.gappssmtp.com header.i=@kernel-dk.20150623.gappssmtp.com header.b="iHncn6eS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 55CC2207FC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E578B8D00A7; Fri, 19 Jun 2020 10:00:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE0598D00A6; Fri, 19 Jun 2020 10:00:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA7CA8D00A7; Fri, 19 Jun 2020 10:00:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0097.hostedemail.com [216.40.44.97]) by kanga.kvack.org (Postfix) with ESMTP id AF56E8D00A6 for ; Fri, 19 Jun 2020 10:00:04 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 4F4CF181AC9CB for ; Fri, 19 Jun 2020 14:00:04 +0000 (UTC) X-FDA: 76946120328.19.shoes58_0b0905e26e19 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id 218731ACDEB for ; Fri, 19 Jun 2020 14:00:03 +0000 (UTC) X-HE-Tag: shoes58_0b0905e26e19 X-Filterd-Recvd-Size: 4532 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Fri, 19 Jun 2020 14:00:02 +0000 (UTC) Received: by mail-pl1-f169.google.com with SMTP id bh7so3950245plb.11 for ; Fri, 19 Jun 2020 07:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=W0/oHl5L/OgRLtiKbTRE0eqcnaMZYrUK7lEVr9b12/U=; b=iHncn6eSfjON+eDoFY3g6l392hGkBpJ9/sqg6OQDmTjtSPGuU/1nFJqrr8EVI2YYpU NLQEPR8NIG7whEKZv9riHCnu/UZGhWMbHV2gQf5p8A0PLyOFQo6suOqp74DJuXscfVCj vQF1wAAsZ5xiyUr+0VP6KXDa0r+t+qZA1vc2MS2wvL7BeZsBzsQOzNF+GVE+JF7sbcCC hRcK+wtM4YHE4V3+7uZu2Uwr09AFZFLqgMGtE/R4zQn50O1DwAQIFJu0f0j9D8S1FUfZ hFB9haK2DmQas1cXLrE7KtyTVOM3hOT0DC4CQcvHLGSpAExBRp6+bpoXEbRjWArtYT8F 1XOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=W0/oHl5L/OgRLtiKbTRE0eqcnaMZYrUK7lEVr9b12/U=; b=C/tzobMysd5rP8a0zEPwKZ5pPAIcJEK552lcN30HvAzJmWIzk+jFPZ4cs678YwR6L2 xje50utXoWjNtRtXpravuyBB7o/GlS3eCeUpxLZyvHMN031Jt4Q6anXFE3hHMC5tO+za lkcv01wql+x73bBpuQ9f/R9ucQUMmBYcC4TyBExGH7gfH2YJn/2s/TLiU42It7612Sk7 iUifxhpxopmTNFdoC9KWMfuE25Ah1GCKJOZCGKZPMNSSM72cRVyOoHTrPKvwQwy2GF8P uZrN1j0vie/NoL9MqRtIVVzLrudxFVHQq440vA6VHVH0+HD5Oia+WooDSAaWBLAp0W2x oG0Q== X-Gm-Message-State: AOAM533W6PAeARaC4KoKwY8WEzb+mY1amaH6hFL+UC9dcnNwu12yqgwO uxnKjyQ0mORIYGal9T124+jlgf6duGUKVw== X-Google-Smtp-Source: ABdhPJydGzaA49RxKTndpzngWW1Y+56Oi+rGziT2geNXezxXPm2HOaO2Q6bEpJ/XQGzafL0LfyJpKA== X-Received: by 2002:a17:902:469:: with SMTP id 96mr377553ple.93.1592575200608; Fri, 19 Jun 2020 07:00:00 -0700 (PDT) Received: from [192.168.1.188] ([66.219.217.173]) by smtp.gmail.com with ESMTPSA id gg10sm5299131pjb.38.2020.06.19.06.59.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 07:00:00 -0700 (PDT) Subject: Re: schedule/sleep over mmget() To: Michal Hocko Cc: linux-mm References: <398032e7-7cbf-3a28-75a7-f6586465f0c6@kernel.dk> <20200619114313.GC12177@dhcp22.suse.cz> From: Jens Axboe Message-ID: Date: Fri, 19 Jun 2020 07:59:59 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200619114313.GC12177@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 218731ACDEB X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 6/19/20 5:43 AM, Michal Hocko wrote: > On Thu 18-06-20 09:20:40, Jens Axboe wrote: >> Hi, >> >> Got a question that I couldn't immediately find an answer to. io_uring >> currently jumps through a few hoops to avoid holding a process mm over >> schedule, and it doesn't look like that's necessary. >> >> Is it fine for a kthread to do mmget/kthread_use_mm at the start, and >> only put/unuse when it exits? Or is it more prudent to drop/re-acquire >> over schedule for potential longer periods of idleness? > > Pinning the address space for a long time is not really ideal. This > would prevent quite a lot of memory to be released when the primary > owner of the address space goes away (willingly or by the OOM killer). > Our documentation says > * Never use this function to pin this address space for an > * unbounded/indefinite amount of time. OK, and that's what I've been adhering to. BTW, while checking for this, the use case in drivers/vhost/vhost.c does not seem to be playing nice. > If you know the kthread is not going to use the mm for some time just > pin the mm struct itsef by mmgrab() and then mmget_not_zero() to get the > address space for your use again. Yep, that's what I'm currently doing. The "normal" io_uring case is that when the process exits, the ring goes away anyway. So for most setups, we should be fine pinning it, but there are also setups where that's not the case. -- Jens Axboe