On Mon, 05 May 2014 11:00:44 -0700 Davidlohr Bueso <davidlohr@xxxxxx> wrote: > > > @@ -339,12 +338,14 @@ static int zram_decompress_page(struct zram *zram, char *mem, u32 index) > > > unsigned long handle; > > > u16 size; > > > > > > - read_lock(&meta->tb_lock); > > > + while(atomic_cmpxchg(&meta->table[index].state, IDLE, ACCESS) != IDLE) > > > + cpu_relax(); > > > + > > > > So... this might be dumb question, but this looks like a spinlock > > implementation. > > > > What advantage does this have over a standard spinlock? > > I was wondering the same thing. Furthermore by doing this you'll loose > the benefits of sharing the lock... your numbers do indicate that it is > for the better. Also, note that hopefully rwlock_t will soon be updated > to be fair and perform up to par with spinlocks, something which is long > overdue. So you could reduce the critical region by implementing the > same granularity, just don't implement your own locking schemes, like > this. It sounds like seqlocks will match this access pattern pretty well? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>