On Thu, Feb 20, 2020 at 05:00:37PM +0100, Jürgen Groß wrote:
> On 20.02.20 16:57, Roger Pau Monné wrote:
> > On Thu, Feb 20, 2020 at 04:50:22PM +0100, Jan Beulich wrote:
> > > On 20.02.2020 16:17, Roger Pau Monné wrote:
> > > > On Thu, Feb 20, 2020 at 04:02:55PM +0100, Jan Beulich wrote:
> > > > >
On 20.02.20 16:57, Roger Pau Monné wrote:
On Thu, Feb 20, 2020 at 04:50:22PM +0100, Jan Beulich wrote:
On 20.02.2020 16:17, Roger Pau Monné wrote:
On Thu, Feb 20, 2020 at 04:02:55PM +0100, Jan Beulich wrote:
On 20.02.2020 15:11, Roger Pau Monné wrote:
On Thu, Feb 20, 2020 at 01:48:54PM
On Thu, Feb 20, 2020 at 04:50:22PM +0100, Jan Beulich wrote:
> On 20.02.2020 16:17, Roger Pau Monné wrote:
> > On Thu, Feb 20, 2020 at 04:02:55PM +0100, Jan Beulich wrote:
> >> On 20.02.2020 15:11, Roger Pau Monné wrote:
> >>> On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
>
On 20.02.2020 16:20, Roger Pau Monné wrote:
> On Thu, Feb 20, 2020 at 04:11:08PM +0100, Jan Beulich wrote:
>> On 20.02.2020 15:38, Roger Pau Monné wrote:
>>> On Thu, Feb 20, 2020 at 03:23:38PM +0100, Jürgen Groß wrote:
On 20.02.20 15:11, Roger Pau Monné wrote:
> On Thu, Feb 20, 2020 at
On 20.02.2020 16:17, Roger Pau Monné wrote:
> On Thu, Feb 20, 2020 at 04:02:55PM +0100, Jan Beulich wrote:
>> On 20.02.2020 15:11, Roger Pau Monné wrote:
>>> On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
Another option is to use the recurse_cpu field of the
associated spin
On Thu, Feb 20, 2020 at 04:11:08PM +0100, Jan Beulich wrote:
> On 20.02.2020 15:38, Roger Pau Monné wrote:
> > On Thu, Feb 20, 2020 at 03:23:38PM +0100, Jürgen Groß wrote:
> >> On 20.02.20 15:11, Roger Pau Monné wrote:
> >>> On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
> On
On Thu, Feb 20, 2020 at 04:02:55PM +0100, Jan Beulich wrote:
> On 20.02.2020 15:11, Roger Pau Monné wrote:
> > On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
> >> Another option is to use the recurse_cpu field of the
> >> associated spin lock: The field is used for recursive locks
>
On 20.02.2020 15:38, Roger Pau Monné wrote:
> On Thu, Feb 20, 2020 at 03:23:38PM +0100, Jürgen Groß wrote:
>> On 20.02.20 15:11, Roger Pau Monné wrote:
>>> On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
On 20.02.2020 13:02, Roger Pau Monne wrote:
> @@ -166,7 +180,8 @@ static
On 20.02.2020 15:11, Roger Pau Monné wrote:
> On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
>> Another option is to use the recurse_cpu field of the
>> associated spin lock: The field is used for recursive locks
>> only, and hence the only conflict would be with
>>
On Thu, Feb 20, 2020 at 03:23:38PM +0100, Jürgen Groß wrote:
> On 20.02.20 15:11, Roger Pau Monné wrote:
> > On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
> > > On 20.02.2020 13:02, Roger Pau Monne wrote:
> > > > I've done some testing and at least the CPU down case is fixed now.
>
On 20.02.20 15:11, Roger Pau Monné wrote:
On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
On 20.02.2020 13:02, Roger Pau Monne wrote:
I've done some testing and at least the CPU down case is fixed now.
Posting early in order to get feedback on the approach taken.
Looks good,
On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
> On 20.02.2020 13:02, Roger Pau Monne wrote:
> > I've done some testing and at least the CPU down case is fixed now.
> > Posting early in order to get feedback on the approach taken.
>
> Looks good, thanks, just a question and two
On 20.02.2020 13:02, Roger Pau Monne wrote:
> I've done some testing and at least the CPU down case is fixed now.
> Posting early in order to get feedback on the approach taken.
Looks good, thanks, just a question and two comments:
> --- a/xen/include/xen/rwlock.h
> +++
Allow a CPU already holding the lock in write mode to also lock it in
read mode. There's no harm in allowing read locking a rwlock that's
already owned by the caller (ie: CPU) in write mode. Allowing such
accesses is required at least for the CPU maps use-case.
In order to do this reserve 12bits
14 matches
Mail list logo