From owner-freebsd-hackers@freebsd.org Tue Dec 29 15:26:10 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 002C34C2ADF for ; Tue, 29 Dec 2020 15:26:10 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4ytT0qdvz4jMT for ; Tue, 29 Dec 2020 15:26:08 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy05.your-server.de ([78.46.172.2]) by dedi548.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1kuGsw-000EIJ-RM; Tue, 29 Dec 2020 16:26:07 +0100 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy05.your-server.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1kuGsw-000SuS-ON; Tue, 29 Dec 2020 16:26:06 +0100 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 761952A1610; Tue, 29 Dec 2020 16:26:06 +0100 (CET) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 87FxUPgQfIs2; Tue, 29 Dec 2020 16:26:06 +0100 (CET) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 1F4D22A165B; Tue, 29 Dec 2020 16:26:06 +0100 (CET) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DjZZaqc-5ZHW; Tue, 29 Dec 2020 16:26:06 +0100 (CET) Received: from shuber-nb-linux.eb.localhost (unknown [10.10.171.18]) by mail.embedded-brains.de (Postfix) with ESMTPSA id EA3062A1610; Tue, 29 Dec 2020 16:26:05 +0100 (CET) Subject: Re: Why is there e_drain_sx and e_drain_mtx? To: Hans Petter Selasky , freebsd-hackers@freebsd.org References: <5eeae691-b7d4-932b-14cc-065a368e77de@embedded-brains.de> <529e7ef5-18e9-0e56-16d3-000d324f42d0@selasky.org> From: Sebastian Huber Message-ID: Date: Tue, 29 Dec 2020 16:26:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <529e7ef5-18e9-0e56-16d3-000d324f42d0@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.102.4/26032/Tue Dec 29 13:42:39 2020) X-Rspamd-Queue-Id: 4D4ytT0qdvz4jMT X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [-2.27 / 15.00]; RCVD_COUNT_SEVEN(0.00)[8]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[embedded-brains.de]; SPAMHAUS_ZRD(0.00)[85.10.215.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[85.10.215.148:from]; NEURAL_HAM_SHORT(-0.97)[-0.969]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; HAS_X_AS(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 15:26:10 -0000 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/