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=-0.7 required=3.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 3420FCA9ED0 for ; Mon, 4 Nov 2019 03:01:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F368721929 for ; Mon, 4 Nov 2019 03:01:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F368721929 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 848F16B0006; Sun, 3 Nov 2019 22:01:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D2236B0007; Sun, 3 Nov 2019 22:01:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C1E56B0008; Sun, 3 Nov 2019 22:01:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id 527996B0006 for ; Sun, 3 Nov 2019 22:01:58 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id DF3938249980 for ; Mon, 4 Nov 2019 03:01:57 +0000 (UTC) X-FDA: 76117095474.13.wood46_4b441df80ee3b X-HE-Tag: wood46_4b441df80ee3b X-Filterd-Recvd-Size: 3536 Received: from r3-18.sinamail.sina.com.cn (r3-18.sinamail.sina.com.cn [202.108.3.18]) by imf47.hostedemail.com (Postfix) with SMTP for ; Mon, 4 Nov 2019 03:01:56 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([221.219.0.223]) by sina.com with ESMTP id 5DBF94A00002F823; Mon, 4 Nov 2019 11:01:54 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 54946815074880 From: Hillf Danton To: Matthew Wilcox Cc: Hillf Danton , linux-mm , Andrew Morton , Shakeel Butt , Minchan Kim , Mel Gorman , Jan Kara , Vladimir Davydov , linux-kernel Subject: Re: [RFC v3] mm: add page preemption Date: Mon, 4 Nov 2019 11:01:44 +0800 Message-Id: <20191104030144.7092-1-hdanton@sina.com> In-Reply-To: <20191103115727.9884-1-hdanton@sina.com> References: <20191103115727.9884-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 Sun, 3 Nov 2019 09:06:49 -0800 Matthew Wilcox wrote: > On Sun, Nov 03, 2019 at 07:57:27PM +0800, 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. > >=20 > > 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. > >=20 > > 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 if > > they have a bunch of workloads to run in datacenter, and some > > difficulty predicting the runtime working set size for every > > individual workload which is sensitive to jitters in lru pages. > >=20 > > Currently pages are reclaimed without prio taken into account; pages > > can be reclaimed from tasks of lower priorities on behalf of > > higher-prio tasks and vice versa. > >=20 > > s/and vice versa/only/ is what we need to make pp by definition, but > > it could not make a sense without prio introduced; otherwise we can > > simply skip deactivating the lru pages based on prio comprison, and > > work is done. > >=20 > > 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 t= he > > size of the int type in the page struct. That room sounds impossible > > without inflating the page struct size, and is walked around by makin= g > > pp depend on CONFIG_64BIT. >=20 > ... and !MEMCG. Which means that your work is uninteresting because al= l > the distros turn on CONFIG_MEMCG. I have no idea which one they turn on by default, ext4, btrfs or xfs, and why, but I think they feel free to do the right, or the left. So do users to configure and build the kernel they need to power their machines, a 4-socket server or a TV-top box. > You still haven't given us any numbers. Or a workload which actually > benefits from this patch. Though I do not know why it is turned on by distros and for what workloads, I would like to try to run a couple of the workloads you may have interest in. Thanks Hillf