All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	Mike Galbraith <umgwanakikbuti@gmail.com>,
	Minchan Kim <minchan@kernel.org>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] zram: Replace bit spinlocks with spinlock_t for PREEMPT_RT.
Date: Wed, 19 Jun 2024 12:01:27 -0600	[thread overview]
Message-ID: <3d984bc3-71d0-4ee6-843f-8cc47a90de2b@kernel.dk> (raw)
In-Reply-To: <20240619175249.lK51lGOx@linutronix.de>

On 6/19/24 11:52 AM, Sebastian Andrzej Siewior wrote:
> On 2024-06-19 11:34:23 [-0600], Jens Axboe wrote:
>> On 6/19/24 9:08 AM, Sebastian Andrzej Siewior wrote:
>>> From: Mike Galbraith <umgwanakikbuti@gmail.com>
>>>
>>> The bit spinlock disables preemption. The spinlock_t lock becomes a sleeping
>>> lock on PREEMPT_RT and it can not be acquired in this context. In this locked
>>> section, zs_free() acquires a zs_pool::lock, and there is access to
>>> zram::wb_limit_lock.
>>>
>>> Use a spinlock_t on PREEMPT_RT for locking and set/ clear ZRAM_LOCK bit after
>>> the lock has been acquired/ dropped.
>>
>> The conditional code depending on CONFIG_PREEMPT_RT is nasty. Why not
>> just get rid of that and use the CONFIG_PREEMPT_RT variants for
>> everything? They are either good enough to work well in general, or it
>> should be redone such that it is.
> 
> That would increase the struct size with lockdep for !RT. But it is
> probably not a concern. Also other bits (besides ZRAM_LOCK) can not be
> added but that wasn't needed in the last few years.

Yeah I really don't think anyone cares about the struct size when
PROVE_LOCKING is on...

-- 
Jens Axboe


  reply	other threads:[~2024-06-19 18:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-19 15:08 [PATCH] zram: Replace bit spinlocks with spinlock_t for PREEMPT_RT Sebastian Andrzej Siewior
2024-06-19 17:34 ` Jens Axboe
2024-06-19 17:52   ` Sebastian Andrzej Siewior
2024-06-19 18:01     ` Jens Axboe [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-03-23 16:18 Sebastian Andrzej Siewior
2023-03-24  4:07 ` Sergey Senozhatsky
2023-03-24  4:32   ` Mike Galbraith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3d984bc3-71d0-4ee6-843f-8cc47a90de2b@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=bigeasy@linutronix.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minchan@kernel.org \
    --cc=senozhatsky@chromium.org \
    --cc=tglx@linutronix.de \
    --cc=umgwanakikbuti@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.