Il 03/09/2013 16:19, Mike Day ha scritto:
>
> Yeah. So how about we say for now that the rcu critical section status
> upon entry to the ram_control_*_iterate functions is undefined. I'll
> make some updates.
Sure.
Paolo
On Tue, Sep 3, 2013 at 10:09 AM, Paolo Bonzini wrote:
>
> Il 03/09/2013 15:56, Mike Day ha scritto:
> >> > +/* this implements a long-running RCU critical section.
> >> > + * When rcu reclaims in the code start to become numerous
> >> > + * it will be necessary to reduce the granularit
Il 03/09/2013 15:56, Mike Day ha scritto:
>> > +/* this implements a long-running RCU critical section.
>> > + * When rcu reclaims in the code start to become numerous
>> > + * it will be necessary to reduce the granularity of this critical
>> > + * section.
>> > + */
>>
>> Plea
On Fri, Aug 30, 2013 at 12:38 PM, Paolo Bonzini wrote:
>
> > @@ -867,7 +879,12 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
> > if (version_id < 4 || version_id > 4) {
> > return -EINVAL;
> > }
> > -
> > +/* this implements a long-running RCU critical se
Il 30/08/2013 18:06, Mike Day ha scritto:
> Changes from V1:
>
> * Omitted locks or rcu critical sections within Some functions that
> read or write the ram_list but are called in a protected context
> (the caller holds the iothread lock, the ram_list mutex, or an rcu
> critical section).
>
Changes from V1:
* Omitted locks or rcu critical sections within Some functions that
read or write the ram_list but are called in a protected context
(the caller holds the iothread lock, the ram_list mutex, or an rcu
critical section).
Allow "unlocked" reads of the ram_list by using an RCU-
