[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |