Received: by 2002:a05:6358:e9c4:b0:b2:91dc:71ab with SMTP id hc4csp5907966rwb; Tue, 9 Aug 2022 06:12:24 -0700 (PDT) X-Google-Smtp-Source: AA6agR5viTH7rp781B6tlVjlm5lxMzSXZAoK1ErI9DbZ8DL06ffVmT2ri7kpaJpoyOGh5uh768BO X-Received: by 2002:a05:6402:4302:b0:43e:18c7:e003 with SMTP id m2-20020a056402430200b0043e18c7e003mr22662447edc.198.1660050744198; Tue, 09 Aug 2022 06:12:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660050744; cv=none; d=google.com; s=arc-20160816; b=QlHyO6W+nq3Mi4ZcebTFsKCJqkWUJXChSfoxvKWePMh4n4RPgbf3D+ag8DuEl7CErT sWnVMZvF4HJ6nM88ZcfeTMN2ZdvAjuZvp3i6gZd4xF1C8D4HfMKTlu1cQ5qFesYbFlOC +u5DQZbLilwewA/MaZ9I2l8P9WntJA+DYWWTp483WSkxDLt8ZR8Zit/n8tBIS+bwnrk4 RY61Nz1I0CqGbncDYtUIkWiy22k5+5GlJx4SK70pOECFcx0JTD0edlxsHjsJP8M+XmbK kZg2kWcFlieAokKdf7eiZGto1AYxl/p5YtO2UJfujABIRwJMdSQUAMjfk8kQKHnhWSUv m6ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=vV1xIkSqBLddF4U1Z3CCLD1KI2sW2FNsic63GPL2qM8=; b=s6vZ/mntYgoqXyHjnVKvHGCFbqV9dGMO5WLAgwxBWmmgX8KebvkkLH96cBgyBtuTaH kfL+2/tyzNbFoKMwGwZtwP/Z1rh44Q3zqPQo10w+tAvkmoqP5+uG+60U68l3lXTLbqLn Ll0GF19ber3R+zfS2ySKATRuJAgPpQosK+sT5SYxx+CkwolwVfe+Wco9EKEcaZT11y/9 4PZBDkxg3FUSXDSvbvd4L8zZgnCB5T2kfdOV8QFyvJEjAuFNC+FDanc5EBr3n7fim0qu skfISOv2evPv9+MoQ3dZ5p7Dt04sAuvoBJ56n+JWk6KWHK2LTdJox4KpkorFWFEMPaSl N5BA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=nIH2rm+x; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z6-20020a05640240c600b0043d0b64b70asi9922458edb.43.2022.08.09.06.11.38; Tue, 09 Aug 2022 06:12:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=nIH2rm+x; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243101AbiHIM6J (ORCPT + 99 others); Tue, 9 Aug 2022 08:58:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50642 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243366AbiHIM6A (ORCPT ); Tue, 9 Aug 2022 08:58:00 -0400 Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B2EA2186D8 for ; Tue, 9 Aug 2022 05:57:57 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id bh13so11278042pgb.4 for ; Tue, 09 Aug 2022 05:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=vV1xIkSqBLddF4U1Z3CCLD1KI2sW2FNsic63GPL2qM8=; b=nIH2rm+xA7k+7yyhm7J2VmFUTLSu6W8yIKZm4yGDdD4BAAJbdxO1WStETNXRxxRQjJ enwTn+rs1U3XsHxkUop3wvIawBfy+ojrlGXHQmHRW1MoNOj9sOpCTo9nKa3HhiDvMBQo jIVpL/bB8AJ8+zpaRxOyirSOrRLvVSRGjIrW0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=vV1xIkSqBLddF4U1Z3CCLD1KI2sW2FNsic63GPL2qM8=; b=IWX8itFqywBIwEQ3wIVlFJqDEpndGzSVcBXj1+PSIqrR3vuSnWrFsH9czJTQbit7Lu 6UbeR+lIyx9kI+ANbz1IwibwiejT0va7g060IKRfnxMLkc2aR1iN56f/RrIHRx0N2Mre Og75+FUX88Z43Rw6mGgFkmr8idUzQPTBkfKSRM/lHFGvw3M3gowLJ18OOOmip3EhJ0Zs TxY04LaJJCbb5B+/gtWDB5N9AM/MlT41SzK+zvlGohb+C+/pW0tqEkb4MhmGP6rGAWAV bZH8HAbLqTsS7Rvs0AkA6bdQvOYMXK7WvW3UGJ1KCIj8xXnU7hw/sd+cweLxN0YivbAP Vx9A== X-Gm-Message-State: ACgBeo1piIFuZjpqMq8W5NkwYAwouGb0O5iTWnk1xPV2wOBBFRGotsJ1 G6UFvm85+r1a4s7lVsw3tOo5fg== X-Received: by 2002:a05:6a00:408e:b0:52e:7ae5:af62 with SMTP id bw14-20020a056a00408e00b0052e7ae5af62mr22972900pfb.20.1660049877273; Tue, 09 Aug 2022 05:57:57 -0700 (PDT) Received: from google.com ([240f:75:7537:3187:8d43:c739:457a:5504]) by smtp.gmail.com with ESMTPSA id u8-20020a170903124800b0016f15140e55sm10666117plh.189.2022.08.09.05.57.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Aug 2022 05:57:56 -0700 (PDT) Date: Tue, 9 Aug 2022 21:57:50 +0900 From: Sergey Senozhatsky To: Jiri Slaby Cc: Sergey Senozhatsky , Linus Torvalds , Linux Kernel Mailing List , minchan@kernel.org, ngupta@vflare.org, Jan Kara , Ted Ts'o , Andreas Dilger , Ext4 Developers List , avromanov@sberdevices.ru, ddrokosov@sberdevices.ru Subject: Re: ext2/zram issue [was: Linux 5.19] Message-ID: References: <702b3187-14bf-b733-263b-20272f53105d@kernel.org> <8710b302-9415-458d-f8a2-b78cc3a96e49@kernel.org> <9fd860a8-4e4f-6a95-5c3f-1b3c4a76cf51@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FSL_HELO_FAKE, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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-ext4@vger.kernel.org On (22/08/09 14:45), Jiri Slaby wrote: > On 09. 08. 22, 14:35, Jiri Slaby wrote: > > But the installer is different. It just creates memory pressure, yet, > > reclaim works well and is able to find memory and go on. I would say > > atomic vs non-atomic retry in the original (pre-5.19) approach makes the > > difference. > > Sorry, I meant no-direct-reclaim (5.19) vs direct-reclaim (pre-5.19). Sure, I understood. This somehow makes me scratch my head and ask if we really want to continue using per-CPU steams. We previously (many years ago) had a list of idle compression streams, which would do compression in preemptible context and we would have only one zs_malloc handle allocation path, which would do direct reclaim (when needed)