Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4704491iob; Sun, 8 May 2022 22:38:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzOYbhhcYDaX2btlZkzcYsCik9osR61jD1YuzYhlr06s1jk1mDK+52V8mDBLy/qDu7tRAVH X-Received: by 2002:a63:f441:0:b0:3c2:7845:976 with SMTP id p1-20020a63f441000000b003c278450976mr12285599pgk.194.1652074717232; Sun, 08 May 2022 22:38:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652074717; cv=none; d=google.com; s=arc-20160816; b=nHWu1FusFljJn27DYXQ8t++ZSd1b/6fLszcKm9lpdPeMilh09J838+x1VG82vYYj0X kIXdGJ5rlaAPpek6TJJkmASElZEAP9qxKmNI1iUZsmlPj0j8zmbGU0Apy+FgDkcZNC8v D2kFZM/w4rnBntAhr/QcDF1qp/YSs/J6HljNY/SsevnsvP+Dpgap0Xn/zrhAdg9JqJ0m +Fys9e5qFCdb3hRCkA5R2HvmRt7vj6JZhoUeaX5nMAujKpGhmH8LFsvhJGopRQ/VCRho urx8wbN0OhXXqnxu5bXNOMnWFJ/3/Rn3rFQkpBhrcF8WZDwg77Hha00qDLEDClcvoyds 7QQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=hp4dZx7e7B5x52z+YxyWS6SnKYtRvgq3EAaeLq15SDs=; b=QQp3E9qq5/tnTlOUphgU14ik4ZZhSxwwiDgMWN4ED7sil/oV55pbl4Z1IuSjHaO2sc nl1eRnj/Ue+/17xh5y/lE2rmPbICK5PuNcyLyq9fCjrDJOFNgJijB3alLGAXboL8iH7W KhE53aLPtrD9sjLhT41JHglDtuHLy+4JRNscT/WfGY6U/b6Nczxe7X2Z0MlTp6CX2Ys4 BTdg15Rpcd8k/vs4J08+G7MMmqiTktM7WBRofDlO6sqQpBRCY8e4UoGBe81iqmi7h4mW raDst6cJvsrsJFZqxOcKD6fpV1b2kJ1eIsKA+OEIesdjFNeCGneJB2ysOlAaVzdtCBy+ eDqw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b="X/t9SQjj"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sberdevices.ru Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id p11-20020a63740b000000b003ab92744f7fsi14264251pgc.405.2022.05.08.22.38.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 May 2022 22:38:36 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b="X/t9SQjj"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sberdevices.ru Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1DDDB1595A1; Sun, 8 May 2022 22:37:14 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239157AbiEDLIl (ORCPT + 99 others); Wed, 4 May 2022 07:08:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348523AbiEDLIk (ORCPT ); Wed, 4 May 2022 07:08:40 -0400 Received: from mail.sberdevices.ru (mail.sberdevices.ru [45.89.227.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FDDA245AF; Wed, 4 May 2022 04:05:00 -0700 (PDT) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mail.sberdevices.ru (Postfix) with ESMTP id 02CF75FD03; Wed, 4 May 2022 14:04:56 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1651662296; bh=hp4dZx7e7B5x52z+YxyWS6SnKYtRvgq3EAaeLq15SDs=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=X/t9SQjjkOtxRknL2/11yTGGnCdaQdeC3Rgdc4Cfz2kZbMdv0Fhw3K1njpK77wv4W 2AQoNDg9pMVfi2xP6mPvTkexgH2spsvBfmkQXzGka+wc4emY56FlJZ8+5YnJo7c8zO jAQsSjhVlapJDRWuRWb102Y7x40zEuZi8DjCmTFaY/c4QSc2KGBrdC0OlMRBo2l200 KQ0yRKfQh5fp1lhxCzwk910D9PTT/w5hJBBjhcOk/Q0CUVYaGubpb7r95CQYc/YhSQ zzrsdZsr/OcT8QaYNLSbweXAFbJ0Ijj9ljdeDpBCpSgzaLpyy5BGsumsLYggPNtrIw CfdSORLyHNHGw== Received: from S-MS-EXCH01.sberdevices.ru (S-MS-EXCH01.sberdevices.ru [172.16.1.4]) by mail.sberdevices.ru (Postfix) with ESMTP; Wed, 4 May 2022 14:04:54 +0300 (MSK) From: Alexey Romanov To: , , , CC: , , , , Alexey Romanov , Dmitry Rokosov Subject: [PATCH v3] zram: remove double compression logic Date: Wed, 4 May 2022 14:04:42 +0300 Message-ID: <20220504110442.59685-1-avromanov@sberdevices.ru> X-Mailer: git-send-email 2.33.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [172.16.1.6] X-ClientProxiedBy: S-MS-EXCH02.sberdevices.ru (172.16.1.5) To S-MS-EXCH01.sberdevices.ru (172.16.1.4) X-KSMG-Rule-ID: 4 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiPhishing: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.30, bases: 2022/05/04 08:31:00 #19348425 X-KSMG-AntiVirus-Status: Clean, skipped X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The 2nd trial allocation under per-cpu presumption has been used to prevent regression of allocation failure. However, it makes trouble for maintenance without significant benefit. The slowpath branch is executed extremely rarely: getting there is problematic. Therefore, we delete this branch. Signed-off-by: Alexey Romanov Signed-off-by: Dmitry Rokosov --- drivers/block/zram/zram_drv.c | 40 ++++++++--------------------------- drivers/block/zram/zram_drv.h | 1 - 2 files changed, 9 insertions(+), 32 deletions(-) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index cb253d80d72b..2eb614769d9d 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -1153,9 +1153,8 @@ static ssize_t debug_stat_show(struct device *dev, down_read(&zram->init_lock); ret = scnprintf(buf, PAGE_SIZE, - "version: %d\n%8llu %8llu\n", + "version: %d\n%8llu\n", version, - (u64)atomic64_read(&zram->stats.writestall), (u64)atomic64_read(&zram->stats.miss_free)); up_read(&zram->init_lock); @@ -1373,7 +1372,6 @@ static int __zram_bvec_write(struct zram *zram, struct bio_vec *bvec, } kunmap_atomic(mem); -compress_again: zstrm = zcomp_stream_get(zram->comp); src = kmap_atomic(page); ret = zcomp_compress(zstrm, src, &comp_len); @@ -1382,39 +1380,20 @@ static int __zram_bvec_write(struct zram *zram, struct bio_vec *bvec, if (unlikely(ret)) { zcomp_stream_put(zram->comp); pr_err("Compression failed! err=%d\n", ret); - zs_free(zram->mem_pool, handle); return ret; } if (comp_len >= huge_class_size) comp_len = PAGE_SIZE; - /* - * handle allocation has 2 paths: - * a) fast path is executed with preemption disabled (for - * per-cpu streams) and has __GFP_DIRECT_RECLAIM bit clear, - * since we can't sleep; - * b) slow path enables preemption and attempts to allocate - * the page with __GFP_DIRECT_RECLAIM bit set. we have to - * put per-cpu compression stream and, thus, to re-do - * the compression once handle is allocated. - * - * if we have a 'non-null' handle here then we are coming - * from the slow path and handle has already been allocated. - */ - if (!handle) - handle = zs_malloc(zram->mem_pool, comp_len, - __GFP_KSWAPD_RECLAIM | - __GFP_NOWARN | - __GFP_HIGHMEM | - __GFP_MOVABLE); - if (!handle) { + + handle = zs_malloc(zram->mem_pool, comp_len, + __GFP_KSWAPD_RECLAIM | + __GFP_NOWARN | + __GFP_HIGHMEM | + __GFP_MOVABLE); + + if (unlikely(!handle)) { zcomp_stream_put(zram->comp); - atomic64_inc(&zram->stats.writestall); - handle = zs_malloc(zram->mem_pool, comp_len, - GFP_NOIO | __GFP_HIGHMEM | - __GFP_MOVABLE); - if (handle) - goto compress_again; return -ENOMEM; } @@ -1975,7 +1954,6 @@ static int zram_add(void) if (ZRAM_LOGICAL_BLOCK_SIZE == PAGE_SIZE) blk_queue_max_write_zeroes_sectors(zram->disk->queue, UINT_MAX); - blk_queue_flag_set(QUEUE_FLAG_STABLE_WRITES, zram->disk->queue); ret = device_add_disk(NULL, zram->disk, zram_disk_groups); if (ret) goto out_cleanup_disk; diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h index 80c3b43b4828..158c91e54850 100644 --- a/drivers/block/zram/zram_drv.h +++ b/drivers/block/zram/zram_drv.h @@ -81,7 +81,6 @@ struct zram_stats { atomic64_t huge_pages_since; /* no. of huge pages since zram set up */ atomic64_t pages_stored; /* no. of pages currently stored */ atomic_long_t max_used_pages; /* no. of maximum pages stored */ - atomic64_t writestall; /* no. of write slow paths */ atomic64_t miss_free; /* no. of missed free */ #ifdef CONFIG_ZRAM_WRITEBACK atomic64_t bd_count; /* no. of pages in backing device */ -- 2.30.1