On Sat, Nov 05, 2016 at 02:49:46PM +0100, Vitaly Wool wrote:
> +/* Read-lock a z3fold page */
> +static void z3fold_page_rlock(struct z3fold_header *zhdr)
> +{
> + while (!atomic_add_unless(&zhdr->page_lock, 1, Z3FOLD_PAGE_WRITE_FLAG))
> + cpu_relax();
> + smp_mb();
> +}
> +
> +
> I understand the reinvention part but you're not quite accurate here
> with the numbers.
>
> E. g. on x86_64:
> (gdb) p sizeof(rwlock_t)
> $1 = 8
I was talking about spinlocks which are 4 bytes. Just use a spinlock then.
rwlocks are usually a bad idea anyways because they often scale far wors
On Sun, Nov 6, 2016 at 12:38 AM, Andi Kleen wrote:
> Vitaly Wool writes:
>
>> Most of z3fold operations are in-page, such as modifying z3fold
>> page header or moving z3fold objects within a page. Taking
>> per-pool spinlock to protect per-page objects is therefore
>> suboptimal, and the idea of
Vitaly Wool writes:
> Most of z3fold operations are in-page, such as modifying z3fold
> page header or moving z3fold objects within a page. Taking
> per-pool spinlock to protect per-page objects is therefore
> suboptimal, and the idea of having a per-page spinlock (or rwlock)
> has been around fo
Most of z3fold operations are in-page, such as modifying z3fold
page header or moving z3fold objects within a page. Taking
per-pool spinlock to protect per-page objects is therefore
suboptimal, and the idea of having a per-page spinlock (or rwlock)
has been around for some time. However, adding on
5 matches
Mail list logo
