Why is there e_drain_sx and e_drain_mtx?
Sebastian Huber
sebastian.huber at embedded-brains.de
Tue Dec 29 15:26:10 UTC 2020
On 29/12/2020 12:07, Hans Petter Selasky wrote:
> On 12/29/20 11:49 AM, Sebastian Huber wrote:
>> Hello,
>>
>> in the epoch based reclamation implementation we have
>>
>> struct epoch {
>> struct ck_epoch e_epoch __aligned(EPOCH_ALIGN);
>> epoch_record_t e_pcpu_record;
>> int e_in_use;
>> int e_flags;
>> struct sx e_drain_sx;
>> struct mtx e_drain_mtx;
>> volatile int e_drain_count;
>> const char *e_name;
>> };
>>
>> The e_drain_sx and e_drain_mtx are only used in
>>
>> void
>> epoch_drain_callbacks(epoch_t epoch)
>> {
>> ...
>> DROP_GIANT();
>>
>> sx_xlock(&epoch->e_drain_sx);
>> mtx_lock(&epoch->e_drain_mtx);
>>
>> ...
>>
>> mtx_unlock(&epoch->e_drain_mtx);
>> sx_xunlock(&epoch->e_drain_sx);
>>
>> PICKUP_GIANT();
>> }
>>
>> Why is there a combination of a shared/exclusive lock and a mutex
>> used like this? Why is a single mutex insufficient?
>>
>
> Hi Sebastian,
>
> The sx_xlock() is there because the operation may sleep and mutexes
> must be dropped when sleeping. We only allow one drain at a time.
>
> The mtx_lock() is there to make the operation atomic with regards to
> the msleep/wakeup sequence. Search for the use of e_drain_mtx . Else
> the msleep and wakeup calls may miss eachother.
Thanks for the explanation. I overlooked the msleep() call.
>
> How is the porting going otherwise? Do you see any performance
> improvements using EPOCH?
It works quite well, even on old chips like the MCF5475. I didn't
monitor the performance over time, but nobody complained so far.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
More information about the freebsd-hackers
mailing list