Page MenuHomeFreeBSD

sbahra_repnop.org (Samy Al Bahra)
User

Projects

User does not belong to any projects.

User Details

User Since
Sep 19 2015, 11:22 PM (212 w, 3 d)

Recent Activity

Oct 14 2018

sbahra_repnop.org added a comment to D17492: Fix early epoch calls.

Ok, call should be fine as well! In all cases, seems like writers are synchronized and any other usage is in the context of a protected section. CI also passes (though I haven't run it through SPARCv9+ and ARM, but we already have RMO and TSO coverage, nothing specific to ARM / SPARC with these changes).

Oct 14 2018, 2:51 AM
sbahra_repnop.org accepted D17492: Fix early epoch calls.

This is actually good too! Sorry for the noise. It was an API violation to call poll on a record that is in a read section, but it seems there is no reason to have that API restriction to begin with at this point. The API restriction is removed now.

Oct 14 2018, 2:06 AM
sbahra_repnop.org accepted D17503: Run epoch calls sooner and more reliably.

Let's merge from upstream if possible.

Oct 14 2018, 2:00 AM
sbahra_repnop.org added a comment to D17503: Run epoch calls sooner and more reliably.

Merged upstream and passes tests. poll return value was changed a bit to only return false if no forward progress was made (no dispatch or no progression of epoch). It will return true if we're in a grace period or if anything has been dispatched.

Oct 14 2018, 2:00 AM
sbahra_repnop.org added a comment to D17503: Run epoch calls sooner and more reliably.

Ok, all these changes here should be good. Thanks. Merging these upstream and then circling back on two issues we wanted to validate:

  • Using writer function on active record (Matt has a simple work-around). As 12 is getting cut, we won't extend the API right now to allow for writer-functions to be used on active records.
  • Usage of call.
Oct 14 2018, 1:22 AM

Oct 11 2018

sbahra_repnop.org added a comment to D17503: Run epoch calls sooner and more reliably.

Thanks for the update. I had a few items come up and will be unable to spend time on this until Saturday. I'll loop back here and I'll try my best to have things ready for Sunday. Unfortunately, Friday won't be realistic at the moment.

Oct 11 2018, 3:34 AM

Oct 10 2018

sbahra_repnop.org requested changes to D17503: Run epoch calls sooner and more reliably.

Ok. I caught up with Matt offline. This doesn't solve the problem at hand. The API is not being used as intended in some areas, so we will work to address that. I would advise against merging this in as it doesn't address the underlying issues:

Oct 10 2018, 9:10 PM
sbahra_repnop.org requested changes to D17492: Fix early epoch calls.
Oct 10 2018, 9:10 PM
sbahra_repnop.org added a comment to D17492: Fix early epoch calls.

Ok. I caught up with Matt offline. This doesn't solve the problem at hand. The API is not being used as intended in some areas, so we will work to address that. I would advise against merging this in as it doesn't address the underlying issues:

Oct 10 2018, 9:10 PM
sbahra_repnop.org added a comment to D17503: Run epoch calls sooner and more reliably.

Is it possible to put these changes upstream first at https://github.com/concurrencykit/ck? We are responsive. You'll get more eye balls on the review and we have the advantage of CI with several torture tests for epoch on both TSO and RMO architectures. We are responsive. Longer term, if you're doing more work here, happy to provide commit privileges as well.

Oct 10 2018, 7:29 PM
sbahra_repnop.org added a comment to D17492: Fix early epoch calls.

The above change should not have any impact if ck_epoch is being correctly used. For that reason, it's good to go. However, I am concerned about a larger problem.

Oct 10 2018, 7:24 PM
sbahra_repnop.org added a comment to D17503: Run epoch calls sooner and more reliably.
In D17503#373529, @jtl wrote:

See previous note in D17492 regarding the assumption that write-side functions are *not* called with-in a read-side critical. Does FreeBSD require that this is permitted?

See my comments in that review.
Regardless of whether that is true, it seems like this change would still be safe. Do you agree?

Oct 10 2018, 7:17 PM
sbahra_repnop.org added a comment to D17503: Run epoch calls sooner and more reliably.

See previous note in D17492 regarding the assumption that write-side functions are *not* called with-in a read-side critical. Does FreeBSD require that this is permitted? If so, there's a few other changes we may want to make and I'll need to do some additional validation.

Oct 10 2018, 4:24 PM
sbahra_repnop.org added a comment to D17492: Fix early epoch calls.

Thanks much for this. Note that the assumption here is a writer thread *should not* be calling ck_epoch_synchronize or write while inside of a read-side critical section. In other words, the active bit must be set to 0. In this situation, the invariant is not violated. If inside a read-side critical section, bets are off. Is the assumption or requirement here that it be safe to call synchronize from with-in a read-side critical section? If so, there are a few other areas we could fix up.

Oct 10 2018, 3:55 PM

Jul 23 2018

sbahra_repnop.org added inline comments to D15905: safer wait-free iteration of shared interrupt handlers.
Jul 23 2018, 5:09 PM

Jul 20 2018

sbahra_repnop.org added inline comments to D15905: safer wait-free iteration of shared interrupt handlers.
Jul 20 2018, 9:49 PM

Jul 12 2018

sbahra_repnop.org added inline comments to D16016: change interrupt event's list of handler from TAILQ to SLIST.
Jul 12 2018, 2:01 AM
sbahra_repnop.org requested changes to D15905: safer wait-free iteration of shared interrupt handlers.
Jul 12 2018, 1:53 AM
sbahra_repnop.org added a comment to D15905: safer wait-free iteration of shared interrupt handlers.

On x86* and other TSO architectures, note that the fences will be emitted. With respect to code movement, the loads will be not be elided in eitherway. I doubt there would be measurable overhead.

Jul 12 2018, 1:37 AM
sbahra_repnop.org added a comment to D15905: safer wait-free iteration of shared interrupt handlers.

@avg Does FreeBSD plan to support Alpha? I honestly wouldn't bother with memory_order_consume unless the FreeBSD model mandates it. All modern architectures are sane with respect to data-dependent loads. Plus, there is a lot more code that would actually need to be using it, that doesn't.

Jul 12 2018, 1:36 AM

Jul 28 2017

sbahra_repnop.org resigned from D8637: buf_ring.h: fix memory order issues..
Jul 28 2017, 5:31 PM

Sep 19 2015

sbahra_repnop.org added a comment to D1945: Buf ring cleanups.

ck_ring has slightly different semantics (it is completely lock-free on consumer, but assumes UINT_MAX operations don't occur during a delay in dequeue) but I took a stab at the buf_ring MP semantics today. I have tested this on RMO architectures and verified the fences with fault injection.

Sep 19 2015, 11:47 PM
sbahra_repnop.org added inline comments to D1945: Buf ring cleanups.
Sep 19 2015, 11:41 PM