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=-5.5 required=3.0 tests=MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 8DC61CA9EAE for ; Tue, 29 Oct 2019 08:41:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 55FF920679 for ; Tue, 29 Oct 2019 08:41:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 55FF920679 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 019EE6B0005; Tue, 29 Oct 2019 04:41:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F0BDB6B0006; Tue, 29 Oct 2019 04:41:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DFA5E6B0007; Tue, 29 Oct 2019 04:41:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0059.hostedemail.com [216.40.44.59]) by kanga.kvack.org (Postfix) with ESMTP id BDC726B0005 for ; Tue, 29 Oct 2019 04:41:56 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 368C5181AF5C2 for ; Tue, 29 Oct 2019 08:41:56 +0000 (UTC) X-FDA: 76096179432.01.river82_4b12e045b9c1b X-HE-Tag: river82_4b12e045b9c1b X-Filterd-Recvd-Size: 4138 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Tue, 29 Oct 2019 08:41:55 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 46353B039; Tue, 29 Oct 2019 08:41:54 +0000 (UTC) Date: Tue, 29 Oct 2019 09:41:53 +0100 From: Michal Hocko To: Hillf Danton Cc: linux-mm , Andrew Morton , linux-kernel , Matthew Wilcox , Johannes Weiner , Shakeel Butt , Minchan Kim , Mel Gorman , Vladimir Davydov , Jan Kara Subject: Re: [RFC v2] mm: add page preemption Message-ID: <20191029084153.GD31513@dhcp22.suse.cz> References: <20191026112808.14268-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191026112808.14268-1-hdanton@sina.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Sat 26-10-19 19:28:08, Hillf Danton wrote: > > The cpu preemption feature makes a task able to preempt other tasks > of lower priorities for cpu. It has been around for a while. > > This work introduces task prio into page reclaiming in order to add > the page preemption feature that makes a task able to preempt other > tasks of lower priorities for page. > > No page will be reclaimed on behalf of tasks of lower priorities > under pp, a two-edge feature that functions only under memory > pressure, laying a barrier to pages flowing to lower prio, and the > nice syscall is what users need to fiddle with it for instance as > no task will be preempted without prio shades, if they have a couple > of workloads that are sensitive to jitters in lru pages, and some > difficulty predicting their working set sizes. > > Currently lru pages are reclaimed under memory pressure without prio > taken into account; pages can be reclaimed from tasks of lower > priorities on behalf of higher-prio tasks and vice versa. > > s/and vice versa/only/ is what we need to make pp by definition, but > it could not make a sense without prio introduced in reclaiming, > otherwise we can simply skip deactivating the lru pages based on prio > comprison, and work is done. > > The introduction consists of two parts. On the page side, we have to > store the page owner task's prio in page, which needs an extra room the > size of the int type in the page struct. > > That room sounds impossible without inflating the page struct size, and > it is not solved but walked around by sharing room with the 32-bit numa > balancing, see 75980e97dacc ("mm: fold page->_last_nid into page->flags > where possible"). > > On the reclaimer side, kswapd's prio is set with the prio of its waker, > and updated in the same manner as kswapd_order. > > V2 is based on next-20191018. > > Changes since v1 > - page->prio shares room with _last_cpupid as per Matthew Wilcox > > Changes since v0 > - s/page->nice/page->prio/ > - drop the role of kswapd's reclaiming prioirty in prio comparison > - add pgdat->kswapd_prio > > Cc: Matthew Wilcox > Cc: Michal Hocko > Cc: Johannes Weiner > Cc: Shakeel Butt > Cc: Minchan Kim > Cc: Mel Gorman > Cc: Vladimir Davydov > Cc: Jan Kara > Signed-off-by: Hillf Danton As already raised in the review of v1. There is no real life usecase described in the changelog. I have also expressed concerns about how such a reclaim would work in the first place (priority inversion, expensive reclaim etc.). Until that is provided/clarified Nacked-by: Michal Hocko Please do not ignore review feedback in the future. -- Michal Hocko SUSE Labs