On Wed, 2016-03-30 at 10:56 +0200, Sebastian Andrzej Siewior wrote:
> * Mike Galbraith | 2016-03-22 11:19:39 [+0100]:
>
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -568,12 +570,13 @@ static int zram_decompress_page(struct z
> > > > unsigned long handle;
> > > > size_t size;
> >
> > -> > > > bit_spin_lock(ZRAM_ACCESS, &meta->table[index].value);
> > +> > > > zram_lock_table(&meta->table[index]);
> > > > handle = meta->table[index].handle;
> > > > size = zram_get_obj_size(meta, index);
> >
> > > > if (!handle || zram_test_flag(meta, index, ZRAM_ZERO)) {
> > > > > > bit_spin_unlock(ZRAM_ACCESS, &meta->table[index].value);
> > +> > > > > > zram_unlock_table(&meta->table[index]);
>
> shouldn't you remove that ZRAM_ACCESS lock here?
Oops, yup.
> ZRAM_ACCESS is the only bit used for locking. ZRAM_ZERO is the only flag
> set / tested.
> Would it be possible to make value u32 and add a spinlock? value is has
> not 64bit on 64bit systems and it uses only the first 23bits for the
> size and bit 24+25 for the two flags we have now. So the size should not
> change on 64bit systems only increase by four byte on 32bit systems.
> That is without the lock debugging of course.
I started going the raw locks route for the allocator instead of
whacking the bit spinlocks, given what it is, but chickened out when I
saw compression, and started thinking of just disabling it for rt
instead. I flipped back, figuring a bloated zram gizmo is better than
no gizmo at all :-/
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
