Re: [Xen-devel] [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.11.15 at 11:36, <ian.campbell@xxxxxxxxxx> wrote:
> On Tue, 2015-11-17 at 17:53 +0000, Andrew Cooper wrote:
>> On 17/11/15 17:39, Jan Beulich wrote:
>> > > > > On 17.11.15 at 18:30, <andrew.cooper3@xxxxxxxxxx> wrote:
>> > > On 17/11/15 17:04, Jan Beulich wrote:
>> > > > > > > On 03.11.15 at 18:58, <malcolm.crossley@xxxxxxxxxx> wrote:
>> > > > > --- a/xen/common/grant_table.c
>> > > > > +++ b/xen/common/grant_table.c
>> > > > > @@ -178,6 +178,10 @@ struct active_grant_entry {
>> > > > >  #define _active_entry(t, e) \
>> > > > >      ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
>> > > > >  
>> > > > > +bool_t grant_rwlock_barrier;
>> > > > > +
>> > > > > +DEFINE_PER_CPU(rwlock_t *, grant_rwlock);
>> > > > Shouldn't these be per grant table? And wouldn't doing so eliminate
>> > > > the main limitation of the per-CPU rwlocks?
>> > > The grant rwlock is per grant table.
>> > That's understood, but I don't see why the above items aren't, too.
>> 
>> Ah - because there is never any circumstance where two grant tables are
>> locked on the same pcpu.
> 
> So per-cpu rwlocks are really a per-pcpu read lock with a fallthrough to a
> per-$resource (here == granttable) rwlock when any writers are present for
> any instance $resource, not just the one where the write lock is desired,
> for the duration of any write lock?

That's not how I understood it, the rwlock isn't per-pCPU (at least not
in what this patch does - it remains a per-domain one). The per-pCPU
object is a pointer to an rwlock, which gets made point to whatever
domain's rwlock the pCPU wants to own.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel