From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5ACC521CA03 for ; Wed, 5 Aug 2026 05:21:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785907272; cv=none; b=S0lUiMJTTtY1D/14vnXpX7xSOFLuRW7hyNhcEtoAygroxuDG94VubNno3IhtnhNzoKO22zAQFVFm2JKat9FVgjoDoEUmPj0PP/kME5mxEFRhZUkW2OZEKp81zaqu5cz9VQBbfs82G8o+3D0EcDoZlv15kwKKBttfhcGl6kqxFpM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785907272; c=relaxed/simple; bh=j5mRqg6aPbrroEQdInkMyu+712mNhbjHho1EAAs8E5w=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZrFPFqpPYeJQ5p5R72+eCx7pJxyMvMqCDWaedx67QNg7mmbsqBqV2fsjN55zb7F5uJTMbnqD8/LWKrvqVSY6Dea9EiLoHTfsvVa4CKRyn7ZNY6RpJw51FnLfdAPjen8xK+gnjOX79mKXY6Y3VSzTasYfJQnJhE+Pqyq3YYhb0h0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=DbVfeu07; arc=none smtp.client-ip=209.85.214.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="DbVfeu07" Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-2d02b4c3601so7101695ad.3 for ; Tue, 04 Aug 2026 22:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1785907269; x=1786512069; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=+Sv2AxrWwmEwL5gdZKZwxZZ9XYDolhlrE00l6kbyHas=; b=DbVfeu07krvKIUw2wUh+W+eCgcJIlbID56KhExOmQym/0xfWEtc55CuoEK/doGjYNa lgfKdtblgNTVqlEsnpUDTyjaWRbpZZobwqi1IRQtM8OmCNuye9/uLZFvNP6qnW5JavRz jYnlUSbQww9IovxpfNprYlU92cLvvLn195Ylc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785907269; x=1786512069; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=+Sv2AxrWwmEwL5gdZKZwxZZ9XYDolhlrE00l6kbyHas=; b=W9rI7UelYnxT+FKoSBVsy8Ec6MySw6DvUVOHr9l3MLX2WSdGEERlWrcTI1Xnrp1LWW J5w4kFE2nUMZNE+kKjHqi7MS9MZcUECCFxnlHaNfoLh5JMNzGMBEIvn/MSIBmY19QE9z CZd+jaqZ5IklybqfBGrjBC7OoNhJHoH0St0HK/d8QTN+0NuvQpdcHFhUN1uSEvkIGvyd S+v3bKVLRAFuq4FPFIAUyXigwyYtKZlTtq2yrepzWMT1wq64/ChV6wBnLEWuDax1e4J8 sUCSLfP7Yiu5qLkjdMboKa/IbosQMBi4cebUmmZerGdB8BFylEfRyJagO5nPj6gIXtzG Rd9g== X-Forwarded-Encrypted: i=1; AHgh+Ror633eID55HGTNGY8FA8UOLVSLSiMGz8xCjES18G0EcQgBIKgfuMVUvEa9gnYJTr9hDtwrEP0j31PIQQo=@vger.kernel.org X-Gm-Message-State: AOJu0YwCqyTLoemC6BIgqGaE9/dPdb/Vea8Em2T+rhPpPmknXtmLGSNB jG30Z7xF3a6s0AsTMQl3jBB30p2/q7TvWefCIT6Rbd2RtNStpf7UENPh6JeweufOlw== X-Gm-Gg: AR+sD12j3ELtLFOw9m88rDBXdI7Cs2SDgcTWpAWAjrguIX8PwelEz2qpxHQVG2X1NNb QGVxSHh3XUNUBZsiyEMuSMbxP5m7cd+yurassGSZ06EMqw2b4shSJTKcNna8R4ZiIaIKM3o47ta F4s2f53P2I7ygY2OJXKiFCZtfniceXwGvNfP9bVYCkp5AJ38vqBi7vykGHlTJ0sQL+E0mvbNRf1 W6SDw0AeVztbMrGIB49At5zJqi7FdahA0CkmKZxsTK9YlznY9RpKQpVNDJmzFJ3MFwgXjHtZTUR LwLShIkuu3oroohbSsVJxneJ1wcNhAikue0atp8cnBeLVpn24G+15LLnD41UDqZr8VsegjSP1zh KyiL6OFYI0phL/RQaoO2Abm/p6ccphYGZHzSkMqvC5U4JZUkkTQgHFbPMWwx2HOJmiPaCddA0SO eMIJgwOUx2ekrSKPmTcgoC5jt/oIYy7KSDirTqEIKfYpN/vFUdYnVoWRl73lqIRRajJOEU0Pp6G zZWzYAZphluLLyUZMRNqc0WnIBAQ39xoPOuSbWu X-Received: by 2002:a17:903:1746:b0:2cf:afe8:b722 with SMTP id d9443c01a7336-2d0ca761e0amr45277575ad.11.1785907269509; Tue, 04 Aug 2026 22:21:09 -0700 (PDT) Received: from google.com ([2a00:79e0:2031:6:32eb:b46b:e9eb:65c5]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d0aa4f35d5sm13841875ad.82.2026.08.04.22.21.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Aug 2026 22:21:08 -0700 (PDT) Date: Wed, 5 Aug 2026 14:21:03 +0900 From: Sergey Senozhatsky To: Barry Song Cc: Sergey Senozhatsky , akpm@linux-foundation.org, bigeasy@linutronix.de, hdanton@sina.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, minchan@kernel.org, ryncsn@gmail.com, yosry.ahmed@linux.dev, surenb@google.com, Dongdong Zhang , Suleiman Souhlal Subject: Re: [RFC PATCH] zram: avoid preemption with CPU-based compression backends Message-ID: References: <20260805005545.66112-1-baohua@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi Barry, On (26/08/05 17:09), Barry Song wrote: > > > This report shows that the zram mutex has become the top lock > > > contributing to UI frame drops, even surpassing mmap_lock, which we > > > are also addressing in multiple threads. :-) > > > > Any chance you can share more details? Are there perhaps RT tasks > > in the mix, priority inversion, starvations and so on? Can proxy > > execution address any of those (if it has relevance to the report > > you are looking at)? > > Hi Sergey, > > talked with our engineers reporting the issue. i believe it is all > about priority inversion. > proxy execution wont resolve it as we have a sleepable zs-malloc > within the mutex. > i believe i need v2 to release the mutex before doing the 2nd stage > zs_malloc with > direct reclaim. Well, we cannot just drop the stream mutex and do sleepable zsmalloc allocation, because this will invalidate compression buffer. So we then will need to do re-compression. Something that I was really happy to drop [1]. Is there any we can do apart from making zram and zsmalloc atomic again? It's hard to believe that this priority inversion hits only zram and no other locks in the system. I really really really don't want to return back to atomic zram/zsmalloc. Is the report you are talking about some test or is it a real world scenario? [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/block/zram/zram_drv.c?h=v6.1.180#n1376