Date: Tue, 29 Dec 2020 16:26:05 +0100 From: Sebastian Huber <sebastian.huber@embedded-brains.de> To: Hans Petter Selasky <hps@selasky.org>, freebsd-hackers@freebsd.org Subject: Re: Why is there e_drain_sx and e_drain_mtx? Message-ID: <d9cb41e2-1c32-b0cf-7778-9fddfc7c14c5@embedded-brains.de> In-Reply-To: <529e7ef5-18e9-0e56-16d3-000d324f42d0@selasky.org> References: <5eeae691-b7d4-932b-14cc-065a368e77de@embedded-brains.de> <529e7ef5-18e9-0e56-16d3-000d324f42d0@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 {
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct ck_epoch e_epo=
ch __aligned(EPOCH_ALIGN);
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 epoch_record_t e_pcpu=
_record;
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int=C2=A0=C2=A0=C2=A0=
=C2=A0 e_in_use;
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int=C2=A0=C2=A0=C2=A0=
=C2=A0 e_flags;
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct sx e_drain_sx;
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct mtx e_drain_mt=
x;
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 volatile int e_drain_=
count;
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 const char *e_name;
>> };
>>
>> The e_drain_sx and e_drain_mtx are only used in
>>
>> void
>> epoch_drain_callbacks(epoch_t epoch)
>> {
>> ...
>> =C2=A0=C2=A0=C2=A0=C2=A0 DROP_GIANT();
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0 sx_xlock(&epoch->e_drain_sx);
>> =C2=A0=C2=A0=C2=A0=C2=A0 mtx_lock(&epoch->e_drain_mtx);
>>
>> ...
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0 mtx_unlock(&epoch->e_drain_mtx);
>> =C2=A0=C2=A0=C2=A0=C2=A0 sx_xunlock(&epoch->e_drain_sx);
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0 PICKUP_GIANT();
>> }
>>
>> Why is there a combination of a shared/exclusive lock and a mutex=20
>> used like this? Why is a single mutex insufficient?
>>
>
> Hi Sebastian,
>
> The sx_xlock() is there because the operation may sleep and mutexes=20
> 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=20
> the msleep/wakeup sequence. Search for the use of e_drain_mtx . Else=20
> 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=20
> improvements using EPOCH?
It works quite well, even on old chips like the MCF5475. I didn't=20
monitor the performance over time, but nobody complained so far.
--=20
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht M=C3=BCnchen
Registernummer: HRB 157899
Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas=
D=C3=B6rfler
Unsere Datenschutzerkl=C3=A4rung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d9cb41e2-1c32-b0cf-7778-9fddfc7c14c5>