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.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 2600BC11F69 for ; Fri, 2 Jul 2021 07:33:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A95F4613F4 for ; Fri, 2 Jul 2021 07:33:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A95F4613F4 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 24DF26B0011; Fri, 2 Jul 2021 03:33:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FDDF6B0036; Fri, 2 Jul 2021 03:33:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 077D26B005D; Fri, 2 Jul 2021 03:33:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0232.hostedemail.com [216.40.44.232]) by kanga.kvack.org (Postfix) with ESMTP id CF56A6B0011 for ; Fri, 2 Jul 2021 03:33:34 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 72648243A3 for ; Fri, 2 Jul 2021 07:33:34 +0000 (UTC) X-FDA: 78316832748.27.1AE8806 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf21.hostedemail.com (Postfix) with ESMTP id 261C6D00016D for ; Fri, 2 Jul 2021 07:33:34 +0000 (UTC) Received: by mail-pl1-f176.google.com with SMTP id c15so5109035pls.13 for ; Fri, 02 Jul 2021 00:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=iFQeUZJpN/P8c4rNnw9ZStEGC/9J57e7oVfkc7jOXBw=; b=mJMs94qsqAKm0pzG+d/8ak5uPFgWva45kkIYnP5i9i11ynkExAicnsBOkuoIaMVVPq rqwpeeplbqDUYVThdtFU/WwAiaHtI6/hGyAuOXS9egERqDiQi8bziv0Zq3pNEotYU1AE /KD8IClawLyRgExTpQkDXSVDep7Nqu032aflrB8St3IR7/QH5wR75f0QW155eRcKYXgh 3ar3esD3sC1KEClkMznsib3UqTjgJoy1sZTSGYiUiFFvG298cl+wR+C3iGRUTznYGrMZ YCqDk/Erp9mfk5XN/9uJ+u6lPAFcHWeUXhI8UMjeLSdOe1jb2sOoFN/eK2HQ+IN7RETu ffFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=iFQeUZJpN/P8c4rNnw9ZStEGC/9J57e7oVfkc7jOXBw=; b=hFOi6pR1NnhFkz7D2QrFf+57D/rpzJjA5JkGK7ZfVAvk2kW4he9uG/0Ow//JaSn+6U EiS79qkBWFrK1mvDbnOgv8685fS9KZBeWSkIptdKmKDdd7d8i/qEpfFph5+s9pszI08a H2HaBiC9ibK/6lcn4I4hSsEEL1U0oAGZKoepCLPzqnNBnb6ceZ4uzvXWLJ7dRzdIl2jd arCQ96sM8gyGX3mc5K/a0ADg3Ba0JSPc2QcDc5MHAVcFWBns7Hhftxwn2aGFP1ge83Kl emxfKFw2MJA/jufNd5IPlli7KFtaEYcUvztbtjN40Vy5OM4lyGnyZ59KOlh7bmiMTcyW xRQg== X-Gm-Message-State: AOAM533VpNLlU0yK31Gfoip/2OUmfVqK0IgNXWvFCshro/XxbiBhk/IO Lfi0auvZFJ6WVMa9a+zolzQ= X-Google-Smtp-Source: ABdhPJzfbBfr0twKNwd1iNtaS41APSdZgzYtJq7ZlrpuaBqpD8i4yGmApJ4Nl/bhtwzQBmHnz014EQ== X-Received: by 2002:a17:902:6e02:b029:128:977c:217d with SMTP id u2-20020a1709026e02b0290128977c217dmr1310954plk.44.1625211213156; Fri, 02 Jul 2021 00:33:33 -0700 (PDT) Received: from google.com ([2620:15c:211:201:e476:fcd4:d1bf:22a2]) by smtp.gmail.com with ESMTPSA id 133sm2438670pfx.39.2021.07.02.00.33.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Jul 2021 00:33:32 -0700 (PDT) Date: Fri, 2 Jul 2021 00:33:30 -0700 From: Minchan Kim To: Zhaoyang Huang Cc: LKML , Andrew Morton , "open list:MEMORY MANAGEMENT" , mm-commits@vger.kernel.org, Sergey Senozhatsky , torvalds@linux-foundation.org, Zhaoyang Huang Subject: Re: [patch 108/192] mm: zram: amend SLAB_RECLAIM_ACCOUNT on zspage_cachep Message-ID: References: <20210630184624.9ca1937310b0dd5ce66b30e7@linux-foundation.org> <20210701015258.BrxjIzdE1%akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=mJMs94qs; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf21.hostedemail.com: domain of minchankim@gmail.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=minchankim@gmail.com X-Stat-Signature: mosjnm1w4qmajkca9u8jezdbmpk4xy69 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 261C6D00016D X-HE-Tag: 1625211214-501635 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 Fri, Jul 02, 2021 at 02:20:42PM +0800, Zhaoyang Huang wrote: > On Fri, Jul 2, 2021 at 1:47 PM Minchan Kim wrote: > > > > On Fri, Jul 02, 2021 at 10:45:09AM +0800, Zhaoyang Huang wrote: > > > On Thu, Jul 1, 2021 at 10:56 PM Minchan Kim wrote: > > > > > > > > On Wed, Jun 30, 2021 at 06:52:58PM -0700, Andrew Morton wrote: > > > > > From: Zhaoyang Huang > > > > > Subject: mm: zram: amend SLAB_RECLAIM_ACCOUNT on zspage_cachep > > > > > > > > > > Zspage_cachep is found be merged with other kmem cache during test, which > > > > > is not good for debug things (zs_pool->zspage_cachep present to be another > > > > > kmem cache in memory dumpfile). It is also neccessary to do so as > > > > > shrinker has been registered for zspage. > > > > > > > > > > Amending this flag can help kernel to calculate SLAB_RECLAIMBLE correctly. > > > > > > > > > > Link: https://lkml.kernel.org/r/1623137297-29685-1-git-send-email-huangzhaoyang@gmail.com > > > > > Signed-off-by: Zhaoyang Huang > > > > > Cc: Minchan Kim > > > > > Cc: Sergey Senozhatsky > > > > > Signed-off-by: Andrew Morton > > > > > > > > Sorry for the late. I don't think this is correct. > > > > > > > > It's true "struct zspage" can be freed by zsmalloc's compaction registerred > > > > by slab shrinker so tempted to make it SLAB_RECLAIM_ACCOUNT. However, it's > > > > quite limited to work only when objects in the zspage are heavily fragmented. > > > > Once the compaction is done, zspage are never discardable until objects are > > > > fragmented again. It means it could hurt other reclaimable slab page reclaiming > > > > since the zspage slab object pins the page. > > > IMHO, kmem cache's reclaiming is NOT affected by SLAB_RECLAIM_ACCOUNT > > > . This flag just affects kmem cache merge[1], the slab page's migrate > > > type[2] and the page's statistics. Actually, zspage's cache DO merged > > > with others even without SLAB_RECLAIM_ACCOUNT currently, which maybe > > > cause zspage's object will NEVER be discarded.(SLAB_MERGE_SAME > > > introduce confusions as people believe the cache will merge with > > > others when it set and vice versa) > > > > > > [1] > > > struct kmem_cache *find_mergeable(size_t size, size_t align, unsigned > > > long flags, const char *name, void (*ctor)(void *)) > > > ... > > > if ((flags & SLAB_MERGE_SAME) != (s->flags & SLAB_MERGE_SAME)) > > > continue; > > > > > > [2] > > > if (s->flags & SLAB_RECLAIM_ACCOUNT) > > > s->allocflags |= __GFP_RECLAIMABLE; > > > > That's the point here. With SLAB_RECLAIM_ACCOUNT, page allocator > > try to allocate pages from MIGRATE_RECLAIMABLE with belief those > > objects are easily reclaimable. Say a page has object A, B, C, D > > and E. A-D are easily reclaimable but E is hard. What happens is > > VM couldn't reclaim the page in the end due to E even though it > > already reclaimed A-D. And the such fragmenation could be spread > > out entire MIGRATE_RECLAIMABLE pageblocks over time. > > That's why I'd like to put zspage into MIGRATE_UNMOVALBE from the > > beginning since I don't think it's easily reclaimble once compaction > > is done. > The slab page could fallback to any migrate type even allocating with It's true but it couldn't be justication to allocate objects from any migration type. We should try to select right type. Please see below. > __GFP_RECLAIMABLE, and there is only one page per slab within zspage's > cache, which will not be affected by compaction, so I think that > doesn't make sense. You shouldn't rely on how many pages the slab has since it's internal implemenation and zspage size also could be changed in the future. And please think about external fragmentaion as well as internal one. What we want to try with allocation type is to group similar lifetime objects together in a pageblock group to help external fragmentation for high-order allocation. Think what happens if the unreclaimable object is located in a reclaimable pageblock. The block couldn't be merged into high-order page in the end so it causes more compaction and smaller available high-order pages in the system.