From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) (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 8AED33E3DBD for ; Wed, 5 Aug 2026 08:46:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785919570; cv=none; b=JmzAgcjpUgSCkyEX0mjqB9C+vyOqNaeLph26rV47hsLKeiShJLnhchpsJJadiKNBVAS428dEI43zm5aUd9h98df+pb9WMZOLmuc4kAm2TNBW3RE8pSZvjUipMe7NtNO2QfjSyvlgqNaccPGEGSnyf5ng5EEAGgK1x4svwpCJbGk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785919570; c=relaxed/simple; bh=s3cj0j0GzPXyMHKtIFRxzUlWz+slShA6PGlQZDd00Ts=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bLjNG+R48RTdyZegqHbSp8cncAeHrfVnIbelReZB7wq49WytlwoRExgca5H+iRNQntQ32mSyKQgPWzBD1sSl9cW3ww8990iyigZHr/A4+zhlMku78rwdOYnqVtqBIj/YMqNn76AhMNFggQgBWWqxChbC8MRvgoT1V7s29p6EzJg= 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=YM38m92i; arc=none smtp.client-ip=209.85.215.176 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="YM38m92i" Received: by mail-pg1-f176.google.com with SMTP id 41be03b00d2f7-c99eaa1f020so716547a12.2 for ; Wed, 05 Aug 2026 01:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1785919568; x=1786524368; 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=Yani87D2vkchIXW/xJvT3dpw4a1HdmFyNSK8oLbUwI4=; b=YM38m92ij0sy0xYPvsl8gQFvtmiTrJQlxr9wFEmQAGDBRITerX/oCaIT2bVhY6SrUD NY7PUCoxJXDj7acMr3VnS9Sw7cwz21+4IrI+KIes7QSm3xYFZM1G71rceQWxlDAIt+JE eaVwAHf/JvQwl7+BX9uhffJQiw7IWvGIejrJA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785919568; x=1786524368; 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=Yani87D2vkchIXW/xJvT3dpw4a1HdmFyNSK8oLbUwI4=; b=NHkrwYHY58rwGjS/2sZVa3tidRsl0Ye/PjhX7YJtGAcmhjvk/iACqfMwVvXnGCo19R 5dy03XiNx43Cz8nBEOniQGsEGiGy1axqWSk96JsLpGUMCYIL3GqO1jKAjwf1Pjwmh5gf n4OPjGgHj5xK6YyMDykPHM94QdQOEuZidEm+lVYYojKzux83F22OiEfMI4LQIMua7GzQ hQArlnngnE5TRwQ+ziHYAtZ9QjFRs/Kd5UbyFS+r8FfyypZKyLkbg74pcqlFpXQFjXSC m+dTd3E3ksrrn4QCywauOWgvzOHu6v760A5b31e1mfAgwKF+7CANzHYAAK1YA4pXOHMn OCTw== X-Forwarded-Encrypted: i=1; AHgh+RrYX6KLQKxqgrG0mFChBRG+Fyg76u+XQEL4NGQmw+RC8d7TwXxEJVho0RKaFoegRy+JofqT7iFNTLaQ5xI=@vger.kernel.org X-Gm-Message-State: AOJu0Yyxty1JtxHrNPoeRR7LkmMw2XmpdR7/jXzN/gWcvr2m0tv+S123 NuBY5VeEaisfrcN8wL0nMb4dqWB3jONvwaT/cZeqXEt1SbrvJ4xnFadUxhEMH7uY9g== X-Gm-Gg: AR+sD11Hww0zC5WP9caK07htoNROmz2VP4fMkIM80Zrf5/pOYPBTizm9xhVDU5Cl5ft zpUpsa7NTLoF2uy2uRmnBd9zlJjAaaTjF8sPkYmgUJcn9rS76KwzOetSeZobJNkSDbySNTlyfgR qm2HJ+B5UB3VPV6oU8GcacXsWU/g6H5Eud4BBBPnivng+sxZuGwjklN1sMwSW8z4jllzc4EOp77 YdVHrXaPSCjHymMv6ADIfok+kKdDT5ZY/l/1pCQVkzw/sIsUvOlfk/l5JS6J9GvRy1gqlMvNs8o Uxuk7UPAQrussyyQs7bH+29kbg3u5Ib/K6rJHV9Ms8YwBQpFujvvRUZC4ABPfdTsDuoa05jr/B5 nL8UQF9MoRSVWkYNa7QP7vKfLFBWU83DJ0nxkwb2gXcuO3CY8+wkTLmRqu/HiVzrrz8tgCmJV+i Cnxw3UcZvRSMuAOyPNx7ieC4rLYQ2hlG3pdyxM5Zh0XkvuUL+hi+UxaRPXlN/vM9AkBH+FDH3vF 3PRqm8eE4fN97kjwEfduShyrzeF X-Received: by 2002:a05:6a20:ac44:b0:3c3:8440:f6da with SMTP id adf61e73a8af0-3cb85ea6fa5mr6036539637.29.1785919567859; Wed, 05 Aug 2026 01:46:07 -0700 (PDT) Received: from google.com ([2a00:79e0:2031:6:8002:2a47:a704:5a58]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cbe708be5bdsm1024528a12.15.2026.08.05.01.46.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Aug 2026 01:46:07 -0700 (PDT) Date: Wed, 5 Aug 2026 17:46:02 +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: On (26/08/05 15:50), Barry Song wrote: > > > 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]. > [..] > BTW, I wonder if compression and decompression could use separate > mutexes. That way, a sleepable zs_malloc() in the compression path > would not block decompression, which is the more latency-sensitive > operation. This sounds interesting. I think all of the S/W backends that we use have stateless decompression, so we probably can just split per-CPU stream mutex for R and W paths w/o the need for any additional scratch buffers. Wanna give it a try? Back to preemption: Is there maybe a common hot preemption point where stream mutex owners get scheduled out? E.g. inside zs_malloc()?