On Monday, July 18, 2011 7:34:11 am Andriy Gapon wrote:
> on 15/05/2011 19:24 Andriy Gapon said the following:
> > on 15/05/2011 19:09 Max Laier said the following:
> >>
> >> I don't think we ever intended to synchronize the local teardown part, and
> >> I
> >> believe that is the correct behavio
on 17/05/2011 18:51 John Baldwin said the following:
> On Tuesday, May 17, 2011 10:34:41 am Andriy Gapon wrote:
>> on 17/05/2011 16:58 John Baldwin said the following:
>>> No, it doesn't quite work that way. It wouldn't work on Alpha for example.
>>>
>>> All load_acq is a load with a memory barrie
on 15/05/2011 19:24 Andriy Gapon said the following:
> on 15/05/2011 19:09 Max Laier said the following:
>>
>> I don't think we ever intended to synchronize the local teardown part, and I
>> believe that is the correct behavior for this API.
>>
>> This version is sufficiently close to what I have,
On Wednesday, May 18, 2011 4:27:50 pm Max Laier wrote:
> On 05/17/2011 01:35 PM, John Baldwin wrote:
> ...
> > Yeah, I already have a patch to do that, but hadn't added atomic ops to
> > critical_enter() and critical_exit(). But it also wasn't as fancy in the
> > critical_exit() case. Here is wha
On Wednesday, May 18, 2011 4:27:50 pm Max Laier wrote:
> On 05/17/2011 01:35 PM, John Baldwin wrote:
> ...
> > Yeah, I already have a patch to do that, but hadn't added atomic ops to
> > critical_enter() and critical_exit(). But it also wasn't as fancy in the
> > critical_exit() case. Here is wha
On 05/17/2011 01:35 PM, John Baldwin wrote:
...
Yeah, I already have a patch to do that, but hadn't added atomic ops to
critical_enter() and critical_exit(). But it also wasn't as fancy in the
critical_exit() case. Here is what I have and I think it might actually
be ok (it doesn't use an atomi
On Tuesday, May 17, 2011 3:16:45 pm Max Laier wrote:
> On 05/17/2011 09:56 AM, John Baldwin wrote:
> > On Tuesday, May 17, 2011 12:20:40 pm Max Laier wrote:
> >> On 05/17/2011 05:16 AM, John Baldwin wrote:
> >> ...
> >>> Index: kern/kern_switch.c
> >>> ==
on 17/05/2011 18:51 John Baldwin said the following:
> On Tuesday, May 17, 2011 10:34:41 am Andriy Gapon wrote:
>> on 17/05/2011 16:58 John Baldwin said the following:
>>> No, it doesn't quite work that way. It wouldn't work on Alpha for example.
>>>
>>> All load_acq is a load with a memory barrie
On 05/17/2011 09:56 AM, John Baldwin wrote:
On Tuesday, May 17, 2011 12:20:40 pm Max Laier wrote:
On 05/17/2011 05:16 AM, John Baldwin wrote:
...
Index: kern/kern_switch.c
===
--- kern/kern_switch.c (revision 221536)
+++ kern/kern_
On Tuesday, May 17, 2011 12:20:40 pm Max Laier wrote:
> On 05/17/2011 05:16 AM, John Baldwin wrote:
> ...
> > Index: kern/kern_switch.c
> > ===
> > --- kern/kern_switch.c (revision 221536)
> > +++ kern/kern_switch.c (working copy)
> >
On Tuesday, May 17, 2011 10:34:41 am Andriy Gapon wrote:
> on 17/05/2011 16:58 John Baldwin said the following:
> > No, it doesn't quite work that way. It wouldn't work on Alpha for example.
> >
> > All load_acq is a load with a memory barrier to order other loads after it.
> > It is still free t
On 05/17/2011 05:16 AM, John Baldwin wrote:
...
Index: kern/kern_switch.c
===
--- kern/kern_switch.c (revision 221536)
+++ kern/kern_switch.c (working copy)
@@ -192,15 +192,22 @@
critical_exit(void)
{
struct thread *td;
- int flags;
on 17/05/2011 16:58 John Baldwin said the following:
> No, it doesn't quite work that way. It wouldn't work on Alpha for example.
>
> All load_acq is a load with a memory barrier to order other loads after it.
> It is still free to load stale data. Only a read-modify-write operation
> would actu
On Tuesday, May 17, 2011 9:46:34 am Andriy Gapon wrote:
> on 17/05/2011 14:56 John Baldwin said the following:
> > On 5/17/11 4:03 AM, Andriy Gapon wrote:
> >> Couldn't [Shouldn't] the whole:
> >>
> > /* Ensure we have up-to-date values. */
> > atomic_add_acq_int(&smp_rv_waiters
on 17/05/2011 14:56 John Baldwin said the following:
> On 5/17/11 4:03 AM, Andriy Gapon wrote:
>> Couldn't [Shouldn't] the whole:
>>
> /* Ensure we have up-to-date values. */
> atomic_add_acq_int(&smp_rv_waiters[0], 1);
> while (smp_rv_waiters[0]< smp_rv_ncpus)
>
On 5/16/11 6:05 PM, Max Laier wrote:
On Monday 16 May 2011 17:54:54 Attilio Rao wrote:
2011/5/16 Max Laier:
On Monday 16 May 2011 16:46:03 John Baldwin wrote:
On Monday, May 16, 2011 4:30:44 pm Max Laier wrote:
On Monday 16 May 2011 14:21:27 John Baldwin wrote:
Yes, we need to fix that. Hum
On 5/17/11 4:03 AM, Andriy Gapon wrote:
on 16/05/2011 23:09 John Baldwin said the following:
is probably just cut and pasted to match the other uses of values in
the smp_rv_waiters[] array.
(atomic_add_acq_int() could spin on architectures where it is implemented
using compare-and-swap (e.g. sp
on 16/05/2011 23:09 John Baldwin said the following:
> On Monday, May 16, 2011 3:27:47 pm Andriy Gapon wrote:
>> on 16/05/2011 21:21 John Baldwin said the following:
>>> How about this:
>> ...
>>> /*
>>> * Shared mutex to restrict busywaits between smp_rendezvous() and
>>> @@ -311,39 +312,62 @@
2011/5/16 Max Laier :
> On Monday 16 May 2011 16:46:03 John Baldwin wrote:
>> On Monday, May 16, 2011 4:30:44 pm Max Laier wrote:
>> > On Monday 16 May 2011 14:21:27 John Baldwin wrote:
>> > > Yes, we need to fix that. Humm, it doesn't preempt when you do a
>> > > critical_exit() though? Or do yo
2011/5/17 Max Laier :
> On Monday 16 May 2011 17:54:54 Attilio Rao wrote:
>> 2011/5/16 Max Laier :
>> > On Monday 16 May 2011 16:46:03 John Baldwin wrote:
>> >> On Monday, May 16, 2011 4:30:44 pm Max Laier wrote:
>> >> > On Monday 16 May 2011 14:21:27 John Baldwin wrote:
>> >> > > Yes, we need to f
On Monday 16 May 2011 17:54:54 Attilio Rao wrote:
> 2011/5/16 Max Laier :
> > On Monday 16 May 2011 16:46:03 John Baldwin wrote:
> >> On Monday, May 16, 2011 4:30:44 pm Max Laier wrote:
> >> > On Monday 16 May 2011 14:21:27 John Baldwin wrote:
> >> > > Yes, we need to fix that. Humm, it doesn't pr
On Monday 16 May 2011 16:46:03 John Baldwin wrote:
> On Monday, May 16, 2011 4:30:44 pm Max Laier wrote:
> > On Monday 16 May 2011 14:21:27 John Baldwin wrote:
> > > Yes, we need to fix that. Humm, it doesn't preempt when you do a
> > > critical_exit() though? Or do you use a hand-rolled critical
On Monday, May 16, 2011 4:30:44 pm Max Laier wrote:
> On Monday 16 May 2011 14:21:27 John Baldwin wrote:
> > Yes, we need to fix that. Humm, it doesn't preempt when you do a
> > critical_exit() though? Or do you use a hand-rolled critical exit that
> > doesn't do a deferred preemption?
>
> Right
On Monday, May 16, 2011 3:27:47 pm Andriy Gapon wrote:
> on 16/05/2011 21:21 John Baldwin said the following:
> > How about this:
> ...
> > /*
> > * Shared mutex to restrict busywaits between smp_rendezvous() and
> > @@ -311,39 +312,62 @@ restart_cpus(cpumask_t map)
> > void
> > smp_rendezvou
On Monday 16 May 2011 14:21:27 John Baldwin wrote:
> On Monday, May 16, 2011 1:46:33 pm Max Laier wrote:
> > I'd like to propose that we move forward with fixing the race, before
> > redesigning the API - please.
> >
> > We agree that there is a problem with the exit rendezvous. Let's fix
> > tha
on 16/05/2011 21:21 John Baldwin said the following:
> How about this:
...
> /*
> * Shared mutex to restrict busywaits between smp_rendezvous() and
> @@ -311,39 +312,62 @@ restart_cpus(cpumask_t map)
> void
> smp_rendezvous_action(void)
> {
> - void* local_func_arg = smp_rv_func_arg;
> -
On Monday, May 16, 2011 1:46:33 pm Max Laier wrote:
> I'd like to propose that we move forward with fixing the race, before
> redesigning the API - please.
>
> We agree that there is a problem with the exit rendezvous. Let's fix that.
> We agree that the generation approach proposed by NetAPP
I'd like to propose that we move forward with fixing the race, before
redesigning the API - please.
We agree that there is a problem with the exit rendezvous. Let's fix that.
We agree that the generation approach proposed by NetAPP is the right way to
go? Can we check it in, then? Again, I'
On Sunday, May 15, 2011 12:36:45 pm Andriy Gapon wrote:
> on 15/05/2011 18:16 John Baldwin said the following:
> > On 5/15/11 10:53 AM, Andriy Gapon wrote:
> >> on 15/05/2011 10:12 Andriy Gapon said the following:
> >>> on 14/05/2011 18:25 John Baldwin said the following:
> Hmmm, so this is no
on 15/05/2011 18:16 John Baldwin said the following:
> On 5/15/11 10:53 AM, Andriy Gapon wrote:
>> on 15/05/2011 10:12 Andriy Gapon said the following:
>>> on 14/05/2011 18:25 John Baldwin said the following:
Hmmm, so this is not actually sufficient. NetApp ran into a very similar
race
on 15/05/2011 19:09 Max Laier said the following:
>
> I don't think we ever intended to synchronize the local teardown part, and I
> believe that is the correct behavior for this API.
>
> This version is sufficiently close to what I have, so I am resonably sure
> that
> it will work for us. I
On Sunday 15 May 2011 11:16:03 John Baldwin wrote:
> On 5/15/11 10:53 AM, Andriy Gapon wrote:
> > on 15/05/2011 10:12 Andriy Gapon said the following:
> >> on 14/05/2011 18:25 John Baldwin said the following:
> >>> Hmmm, so this is not actually sufficient. NetApp ran into a very
> >>> similar race
On 5/15/11 10:53 AM, Andriy Gapon wrote:
on 15/05/2011 10:12 Andriy Gapon said the following:
on 14/05/2011 18:25 John Baldwin said the following:
Hmmm, so this is not actually sufficient. NetApp ran into a very similar race
with virtual CPUs in BHyVe. In their case because virtual CPUs are t
on 15/05/2011 10:12 Andriy Gapon said the following:
> on 14/05/2011 18:25 John Baldwin said the following:
>> Hmmm, so this is not actually sufficient. NetApp ran into a very similar
>> race
>> with virtual CPUs in BHyVe. In their case because virtual CPUs are threads
>> that
>> can be preempt
on 15/05/2011 07:33 Max Laier said the following:
> On Saturday 14 May 2011 11:25:36 John Baldwin wrote:
>> On 5/13/11 9:43 AM, Andriy Gapon wrote:
>>> This is a change in vein of what I've been doing in the xcpu branch and
>>> it's supposed to fix the issue by the recent commit that (probably
>>>
on 14/05/2011 18:25 John Baldwin said the following:
> Hmmm, so this is not actually sufficient. NetApp ran into a very similar race
> with virtual CPUs in BHyVe. In their case because virtual CPUs are threads
> that
> can be preempted, they have a chance at a longer race.
>
> The problem that
on 14/05/2011 18:25 John Baldwin said the following:
> On 5/13/11 9:43 AM, Andriy Gapon wrote:
>>
>> This is a change in vein of what I've been doing in the xcpu branch and it's
>> supposed to fix the issue by the recent commit that (probably
>> unintentionally)
>> stress-tests smp_rendezvous in T
On Saturday 14 May 2011 11:25:36 John Baldwin wrote:
> On 5/13/11 9:43 AM, Andriy Gapon wrote:
> > This is a change in vein of what I've been doing in the xcpu branch and
> > it's supposed to fix the issue by the recent commit that (probably
> > unintentionally) stress-tests smp_rendezvous in TSC c
On 5/13/11 9:43 AM, Andriy Gapon wrote:
This is a change in vein of what I've been doing in the xcpu branch and it's
supposed to fix the issue by the recent commit that (probably unintentionally)
stress-tests smp_rendezvous in TSC code.
Non-essential changes:
- ditch initial, and in my opinion
on 13/05/2011 20:13 Max Laier said the following:
> Disregard this ... I misread the diff. You are indeed using [2] correctly as
> the "all-clear" semaphore. I still believe, that it is safer/cleaner to do
> this spin before releasing the lock instead (see my patch).
Maybe. I consider my appr
on 13/05/2011 18:50 Max Laier said the following:
> On Friday 13 May 2011 11:28:33 Andriy Gapon wrote:
>> on 13/05/2011 17:41 Max Laier said the following:
>>> this ncpus isn't the one you are looking for.
>>
>> Thank you!
>>
>> Here's an updated patch:
>
> Can you attach the patch, so I can apply
On Friday 13 May 2011 11:50:57 Max Laier wrote:
> On Friday 13 May 2011 11:28:33 Andriy Gapon wrote:
> > on 13/05/2011 17:41 Max Laier said the following:
> > > this ncpus isn't the one you are looking for.
> >
> > Thank you!
>
> > Here's an updated patch:
> Can you attach the patch, so I can app
On Friday 13 May 2011 11:28:33 Andriy Gapon wrote:
> on 13/05/2011 17:41 Max Laier said the following:
> > this ncpus isn't the one you are looking for.
>
> Thank you!
>
> Here's an updated patch:
Can you attach the patch, so I can apply it locally. This code is really hard
to read without con
on 13/05/2011 17:41 Max Laier said the following:
> this ncpus isn't the one you are looking for.
Thank you!
Here's an updated patch:
Index: sys/kern/subr_smp.c
===
--- sys/kern/subr_smp.c (revision 221835)
+++ sys/kern/subr_smp.c (
On Friday 13 May 2011 09:43:25 Andriy Gapon wrote:
> This is a change in vein of what I've been doing in the xcpu branch and
> it's supposed to fix the issue by the recent commit that (probably
> unintentionally) stress-tests smp_rendezvous in TSC code.
>
> Non-essential changes:
> - ditch initial
On Friday 13 May 2011 09:43:25 Andriy Gapon wrote:
> This is a change in vein of what I've been doing in the xcpu branch and
> it's supposed to fix the issue by the recent commit that (probably
> unintentionally) stress-tests smp_rendezvous in TSC code.
>
> Non-essential changes:
> - ditch initial
This is a change in vein of what I've been doing in the xcpu branch and it's
supposed to fix the issue by the recent commit that (probably unintentionally)
stress-tests smp_rendezvous in TSC code.
Non-essential changes:
- ditch initial, and in my opinion useless, pre-setup rendezvous in
smp_rende
47 matches
Mail list logo