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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 338AAC4321E for ; Tue, 29 Nov 2022 14:21:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A5ECD6B0072; Tue, 29 Nov 2022 09:21:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A0D216B0074; Tue, 29 Nov 2022 09:21:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D41B6B0075; Tue, 29 Nov 2022 09:21:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7D1886B0072 for ; Tue, 29 Nov 2022 09:21:37 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 90A74805E4 for ; Tue, 29 Nov 2022 11:53:43 +0000 (UTC) X-FDA: 80186320326.25.92291F1 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by imf24.hostedemail.com (Postfix) with ESMTP id 2D58718000D for ; Tue, 29 Nov 2022 11:53:41 +0000 (UTC) Received: by mail-pj1-f46.google.com with SMTP id q17-20020a17090aa01100b002194cba32e9so2211029pjp.1 for ; Tue, 29 Nov 2022 03:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kdr4qqlcDI/C93KNdQRixFidR215xARpd9gca61oCW8=; b=IYWVhThXpeOBdgTAf4CZcma2/HYD9mVPKvq70DQdaREb42zfZ4X8jUCUp8Xcwz2mqG uSti/5atO+xgqDNwbpZN2XpIbDLxZ1KjIGUh3Cn3YJaTDObTos63C+DFDX/tWAGGniNr cS65A7Be80SZZ4eJt9prLujUrkqJS4bEhDic8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kdr4qqlcDI/C93KNdQRixFidR215xARpd9gca61oCW8=; b=oKA4aGdVNariNRQgkDZr5x9OQce0O008GLC1SxIQa0J9VQH6/W6wKj8WJWPtFAwWwd 9jwCg4ICc0IMepJBoi+/0gBV+c4YSujmQvhB80VmlSioeEj7/SdWQDIiLtrGGyNCSpZT 8xpzKX2WcXkdUEp/tNsufva0ZZuukpCkCagDFqcopTsVRwDWPUHKhExChis0r7zMY6LL ZjmtIdqFTQEfe0mjZUiaQcI8rBvIT+UR6r5OmQHFCqHa9YECdJx2lCwEYcRZkQ99hajj o2Ro8nb4x6GDNK3EyccGf8d/7Qepyp5zva1vCAAdIDvte2Ds+DkM8U8caODiU5bVQgZu ZmdQ== X-Gm-Message-State: ANoB5plnRjaw0Ph9HsG/NymfT2+Dj/pu7S6VhWSCYx5RqrSXYibvx66D 2rTcg1DxOPhk1+cVlmOpRzAJEDP8S2tt5OY4Wi7iGA== X-Google-Smtp-Source: AA0mqf7QVFpK5qVliFVVzpjCWhALK8q6Yi2gWV5WFWKFjlfkiWqWFL3UMvyWpK0PekfmGrXyPTajL5gnSxG7CQ28LxI= X-Received: by 2002:a17:90a:fa16:b0:218:f998:a9c0 with SMTP id cm22-20020a17090afa1600b00218f998a9c0mr27160673pjb.185.1669722821039; Tue, 29 Nov 2022 03:53:41 -0800 (PST) MIME-Version: 1.0 References: <20221128191616.1261026-1-nphamcs@gmail.com> <20221128191616.1261026-5-nphamcs@gmail.com> In-Reply-To: <20221128191616.1261026-5-nphamcs@gmail.com> From: Vitaly Wool Date: Tue, 29 Nov 2022 12:53:30 +0100 Message-ID: Subject: Re: [PATCH v7 4/6] zsmalloc: Add a LRU to zs_pool to keep track of zspages in LRU order To: Nhat Pham Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, minchan@kernel.org, ngupta@vflare.org, senozhatsky@chromium.org, sjenning@redhat.com, ddstreet@ieee.org Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669722822; a=rsa-sha256; cv=none; b=eZusRLludDWIhi6GYFXc7POXndF01el/W2UCo8Qmm1kkJFGU5ntGas20JmWlS/az9px/7d deE8FgkS3RqZN5DhqsaiMrUccY+IqhookEd55oP1eZRo565byBvTWJ5VZ1baPco3KtCWQl oDEBwCIBzQuQv3q8/j07fHJNgReR0N0= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=konsulko.com header.s=google header.b=IYWVhThX; spf=pass (imf24.hostedemail.com: domain of vitaly.wool@konsulko.com designates 209.85.216.46 as permitted sender) smtp.mailfrom=vitaly.wool@konsulko.com; dmarc=pass (policy=none) header.from=konsulko.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669722822; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=kdr4qqlcDI/C93KNdQRixFidR215xARpd9gca61oCW8=; b=nod15l6eQfPEA+LZit5d/5ki14eLFdnTarWeDJFjAvW3IjnYU71sJbodBCoTEehrAIjQlj ZQQqkPBkR/1LHSEFcZtKEt6T0Q+VKweK7rfH4L3WhIwnmJyMHAWmBsS1iFJF9L10yE+rHZ by+5awXQ8++l6nitHfQ0If3PAJAy3iQ= X-Stat-Signature: fbfzn6fkrnk46k5inwb634zmbz1sjqbc Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=konsulko.com header.s=google header.b=IYWVhThX; spf=pass (imf24.hostedemail.com: domain of vitaly.wool@konsulko.com designates 209.85.216.46 as permitted sender) smtp.mailfrom=vitaly.wool@konsulko.com; dmarc=pass (policy=none) header.from=konsulko.com X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 2D58718000D X-Rspam-User: X-HE-Tag: 1669722821-1762 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 Mon, Nov 28, 2022 at 8:16 PM Nhat Pham wrote: > > This helps determines the coldest zspages as candidates for writeback. > > Signed-off-by: Nhat Pham > --- > mm/zsmalloc.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 50 insertions(+) > > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c > index 5427a00a0518..b1bc231d94a3 100644 > --- a/mm/zsmalloc.c > +++ b/mm/zsmalloc.c > @@ -239,6 +239,11 @@ struct zs_pool { > /* Compact classes */ > struct shrinker shrinker; > > +#ifdef CONFIG_ZPOOL > + /* List tracking the zspages in LRU order by most recently added object */ > + struct list_head lru; > +#endif > + > #ifdef CONFIG_ZSMALLOC_STAT > struct dentry *stat_dentry; > #endif > @@ -260,6 +265,12 @@ struct zspage { > unsigned int freeobj; > struct page *first_page; > struct list_head list; /* fullness list */ > + > +#ifdef CONFIG_ZPOOL > + /* links the zspage to the lru list in the pool */ > + struct list_head lru; > +#endif > + > struct zs_pool *pool; > #ifdef CONFIG_COMPACTION > rwlock_t lock; > @@ -953,6 +964,9 @@ static void free_zspage(struct zs_pool *pool, struct size_class *class, > } > > remove_zspage(class, zspage, ZS_EMPTY); > +#ifdef CONFIG_ZPOOL > + list_del(&zspage->lru); > +#endif > __free_zspage(pool, class, zspage); > } > > @@ -998,6 +1012,10 @@ static void init_zspage(struct size_class *class, struct zspage *zspage) > off %= PAGE_SIZE; > } > > +#ifdef CONFIG_ZPOOL > + INIT_LIST_HEAD(&zspage->lru); > +#endif > + > set_freeobj(zspage, 0); > } > > @@ -1270,6 +1288,31 @@ void *zs_map_object(struct zs_pool *pool, unsigned long handle, > obj_to_location(obj, &page, &obj_idx); > zspage = get_zspage(page); > > +#ifdef CONFIG_ZPOOL > + /* > + * Move the zspage to front of pool's LRU. > + * > + * Note that this is swap-specific, so by definition there are no ongoing > + * accesses to the memory while the page is swapped out that would make > + * it "hot". A new entry is hot, then ages to the tail until it gets either > + * written back or swaps back in. > + * > + * Furthermore, map is also called during writeback. We must not put an > + * isolated page on the LRU mid-reclaim. > + * > + * As a result, only update the LRU when the page is mapped for write > + * when it's first instantiated. > + * > + * This is a deviation from the other backends, which perform this update > + * in the allocation function (zbud_alloc, z3fold_alloc). > + */ > + if (mm == ZS_MM_WO) { > + if (!list_empty(&zspage->lru)) > + list_del(&zspage->lru); > + list_add(&zspage->lru, &pool->lru); > + } > +#endif > + > /* > * migration cannot move any zpages in this zspage. Here, pool->lock > * is too heavy since callers would take some time until they calls > @@ -1988,6 +2031,9 @@ static void async_free_zspage(struct work_struct *work) > VM_BUG_ON(fullness != ZS_EMPTY); > class = pool->size_class[class_idx]; > spin_lock(&pool->lock); > +#ifdef CONFIG_ZPOOL > + list_del(&zspage->lru); > +#endif > __free_zspage(pool, class, zspage); > spin_unlock(&pool->lock); > } > @@ -2299,6 +2345,10 @@ struct zs_pool *zs_create_pool(const char *name) > */ > zs_register_shrinker(pool); > > +#ifdef CONFIG_ZPOOL > + INIT_LIST_HEAD(&pool->lru); > +#endif I think the amount of #ifdefs here becomes absolutely overwhelming. Not that zsmalloc code was very readable before, but now it is starting to look like a plain disaster. Thanks, Vitaly > + > return pool; > > err: > -- > 2.30.2