| Message ID | 20240906141520.730009-1-bigeasy@linutronix.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | zram: Replace bit spinlocks with a spinlock_t. | expand |
On 9/6/24 8:14 AM, Sebastian Andrzej Siewior wrote: > Hi, > > this is follow up to the previous posting, making the lock > unconditionally. The original problem with bit spinlock is that it > disabled preemption and the following operations (within the atomic > section) perform operations that may sleep on PREEMPT_RT. Mike expressed > that he would like to keep using zram on PREEMPT_RT. Looks good to me: Reviewed-by: Jens Axboe <axboe@kernel.dk>
On 2024-09-06 08:31:23 [-0600], Jens Axboe wrote: > On 9/6/24 8:14 AM, Sebastian Andrzej Siewior wrote: > > Hi, > > > > this is follow up to the previous posting, making the lock > > unconditionally. The original problem with bit spinlock is that it > > disabled preemption and the following operations (within the atomic > > section) perform operations that may sleep on PREEMPT_RT. Mike expressed > > that he would like to keep using zram on PREEMPT_RT. > > Looks good to me: > > Reviewed-by: Jens Axboe <axboe@kernel.dk> Thank you. This is routed via your tree, right? Sebastian
On 9/6/24 8:48 AM, Sebastian Andrzej Siewior wrote: > On 2024-09-06 08:31:23 [-0600], Jens Axboe wrote: >> On 9/6/24 8:14 AM, Sebastian Andrzej Siewior wrote: >>> Hi, >>> >>> this is follow up to the previous posting, making the lock >>> unconditionally. The original problem with bit spinlock is that it >>> disabled preemption and the following operations (within the atomic >>> section) perform operations that may sleep on PREEMPT_RT. Mike expressed >>> that he would like to keep using zram on PREEMPT_RT. >> >> Looks good to me: >> >> Reviewed-by: Jens Axboe <axboe@kernel.dk> > Thank you. > This is routed via your tree, right? I can certainly take it - Minchan let me know if you have concerns.
On Fri, 06 Sep 2024 16:14:42 +0200, Sebastian Andrzej Siewior wrote: > this is follow up to the previous posting, making the lock > unconditionally. The original problem with bit spinlock is that it > disabled preemption and the following operations (within the atomic > section) perform operations that may sleep on PREEMPT_RT. Mike expressed > that he would like to keep using zram on PREEMPT_RT. > > v3…v4: https://lore.kernel.org/linux-block/20240705125058.1564001-1-bigeasy@linutronix.de > - Inline lock init into zram_meta_alloc(). > > [...] Applied, thanks! [1/3] zram: Replace bit spinlocks with a spinlock_t. commit: 9518e5bfaae19447d657983d0628062ab6712610 [2/3] zram: Remove ZRAM_LOCK commit: 6086aeb49e3d9e25165769b2a0a13ff67f98a1a2 [3/3] zram: Shrink zram_table_entry::flags. commit: 68d20eb60efbdc80662efedeb088353e9c4aa17f Best regards,
Hi, this is follow up to the previous posting, making the lock unconditionally. The original problem with bit spinlock is that it disabled preemption and the following operations (within the atomic section) perform operations that may sleep on PREEMPT_RT. Mike expressed that he would like to keep using zram on PREEMPT_RT. v3…v4: https://lore.kernel.org/linux-block/20240705125058.1564001-1-bigeasy@linutronix.de - Inline lock init into zram_meta_alloc(). v2…v3 https://lore.kernel.org/all/20240620153556.777272-1-bigeasy@linutronix.de/ - Do "size_t index" within the for loop. v1…v2: https://lore.kernel.org/all/20240619150814.BRAvaziM@linutronix.de/: - Add the spinlock_t unconditionally - Remove ZRAM_LOCK since it has no user after the lock has been added. - Make zram_table_entry::flags an integer so struct zram_table_entry does not gain additional weight. Sebastian