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=-8.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 5CB58C4CECE for ; Thu, 17 Oct 2019 03:45:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 11D1620872 for ; Thu, 17 Oct 2019 03:45:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="v5afzdbr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 11D1620872 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A8C388E0006; Wed, 16 Oct 2019 23:45:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A3D2A8E0001; Wed, 16 Oct 2019 23:45:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 953238E0006; Wed, 16 Oct 2019 23:45:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0208.hostedemail.com [216.40.44.208]) by kanga.kvack.org (Postfix) with ESMTP id 75B3F8E0001 for ; Wed, 16 Oct 2019 23:45:46 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 01C1E6126 for ; Thu, 17 Oct 2019 03:45:46 +0000 (UTC) X-FDA: 76051887492.22.dock12_899a2c6b8a12a X-HE-Tag: dock12_899a2c6b8a12a X-Filterd-Recvd-Size: 4800 Received: from mail-yb1-f196.google.com (mail-yb1-f196.google.com [209.85.219.196]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Thu, 17 Oct 2019 03:45:45 +0000 (UTC) Received: by mail-yb1-f196.google.com with SMTP id h7so276048ybp.0 for ; Wed, 16 Oct 2019 20:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qqAG5zLfngp0Y9W45g/OmRh5/iG/yT/9qLn4n6Unqk8=; b=v5afzdbrUk+KNxnH535CP89upFs4qZ6J7CXnNO8nPJh7CyQnlWeMPpvswJMs5Xdec2 aR9L72byxia1HAt/xb4hmOpxMH4aDBjoIdFeE/6y060regR1g6f8GZhoXLhrE1W2r2KC mZrBvs7lTiXTKE9ZS7m6YGBBzEbfmanSkA01Nk4YUIqZlvxaYaMRJdc4LlucCPrpcVdE WPgYzAW2LxblMXrDdeLXRAToIZr3qi2tlW3c80TEbZhdooTqJFyGa4KFYEFCIIdfENFj vFHp4UqRY4dZmTdc5OeJPYvG1hNbES6417d2N1DqNaYT3YL233fjXijrHymLxkLOIH1e fNBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qqAG5zLfngp0Y9W45g/OmRh5/iG/yT/9qLn4n6Unqk8=; b=NGynd7hNCBUPIF8NoSAj60sHCCa96tKPrplL1BdoOsjnzv+W44sS4iFB4kmlrwkSyP f9hHgc4TsRJ+1tV1qxAEN+TKDHExjfgX/UIoZD4y8ouONQOpHi7P+Q+u27E4OaTPzJB5 k1nauosmeBGwhAQuXy36jE/Ka0bpfBZebHnJ6Bno/04vEaVp+Avp5OlUi3rrQXDDYdzg PmNCq6t7IKrqvI/tvNmx0GVWpaDXRO8WQuddUOoBHqRUqxGwGHA+8JRqg0pmJLzXuduj 7Gv4t9cdkd9+8NnlRtCk4v80ddFQjCtyncU8OU0pP3/01LhjOmywVkZ4TtBVCN1JdrOQ 7bLg== X-Gm-Message-State: APjAAAWBCif/OENc53lSTGOqSgHBnGo7VwpGqHQyzRfcg4IpIvREbVo9 Qf1AWH53nhGuj19Qb5Ah48ebhdANQZziBn8SIksd+A== X-Google-Smtp-Source: APXvYqwI7C8T+z1xB43hCUFEP5SPIEvBwe8hBhtXGvmI8gDBl6iM3l8J/5maNtLGeK4hpa4mpTiaJmYVPEtc+lPlCSo= X-Received: by 2002:a25:c883:: with SMTP id y125mr751178ybf.358.1571283944468; Wed, 16 Oct 2019 20:45:44 -0700 (PDT) MIME-Version: 1.0 References: <20191016221148.F9CCD155@viggo.jf.intel.com> In-Reply-To: <20191016221148.F9CCD155@viggo.jf.intel.com> From: Shakeel Butt Date: Wed, 16 Oct 2019 20:45:33 -0700 Message-ID: Subject: Re: [PATCH 0/4] [RFC] Migrate Pages in lieu of discard To: Dave Hansen Cc: LKML , Linux MM , Dan Williams , Jonathan Adams Content-Type: text/plain; charset="UTF-8" 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 Wed, Oct 16, 2019 at 3:49 PM Dave Hansen wrote: > > We're starting to see systems with more and more kinds of memory such > as Intel's implementation of persistent memory. > > Let's say you have a system with some DRAM and some persistent memory. > Today, once DRAM fills up, reclaim will start and some of the DRAM > contents will be thrown out. Allocations will, at some point, start > falling over to the slower persistent memory. > > That has two nasty properties. First, the newer allocations can end > up in the slower persistent memory. Second, reclaimed data in DRAM > are just discarded even if there are gobs of space in persistent > memory that could be used. > > This set implements a solution to these problems. At the end of the > reclaim process in shrink_page_list() just before the last page > refcount is dropped, the page is migrated to persistent memory instead > of being dropped. > > While I've talked about a DRAM/PMEM pairing, this approach would > function in any environment where memory tiers exist. > > This is not perfect. It "strands" pages in slower memory and never > brings them back to fast DRAM. Other things need to be built to > promote hot pages back to DRAM. > > This is part of a larger patch set. If you want to apply these or > play with them, I'd suggest using the tree from here. It includes > autonuma-based hot page promotion back to DRAM: > > http://lkml.kernel.org/r/c3d6de4d-f7c3-b505-2e64-8ee5f70b2118@intel.com > > This is also all based on an upstream mechanism that allows > persistent memory to be onlined and used as if it were volatile: > > http://lkml.kernel.org/r/20190124231441.37A4A305@viggo.jf.intel.com The memory cgroup part of the story is missing here. Since PMEM is treated as slow DRAM, shouldn't its usage be accounted to the corresponding memcg's memory/memsw counters and the migration should not happen for memcg limit reclaim? Otherwise some jobs can hog the whole PMEM. Also what happens when PMEM is full? Can the memory migrated to PMEM be reclaimed (or discarded)? Shakeel