From owner-freebsd-hackers@freebsd.org Thu Aug 23 14:37:30 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52A3C108F5A6 for ; Thu, 23 Aug 2018 14:37:30 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C5C4374D05 for ; Thu, 23 Aug 2018 14:37:29 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf1-x436.google.com with SMTP id k19-v6so2820311pfi.1 for ; Thu, 23 Aug 2018 07:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=/M0M/E9cFsyciIQnXCjdDoAFRWV3IuI3A2Cotbg5uHI=; b=iNrqzNgqupFmj3vtVoTTOU6Q+kof3F92DI75zYCqmYgfFR3JXjgOQvmwRLO6SvD7fS /BTZw8gDpgqA/HdvusqQ3y+CA11KDMGyk1Q9Z//OrGlSMN7CHt6KqAOyOvMVv+3BBBft ZmAd1wdYpSp7i+pYVutBjLodRn/+hDUjEXNIrxjHbZwR7nbmuKl9aPhJOCBIKbKm5u3D vmeXByclSAwJ2EbwM5UFt27dIq6Tgsiav6Ff2Ulj5wAsHCGPhDwkxqdzWKSwzP0f+QDa +GVtd9yMKbgnKCnUfAtyJJzLrXb5FM231FvBxwHHVPi1EPh7eWNDXHepxzmx0O4ZguXq 0mKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=/M0M/E9cFsyciIQnXCjdDoAFRWV3IuI3A2Cotbg5uHI=; b=j0h2cZ331Fttg38UTEiDaOEeP5GrGEZvTnN+siiJImFw9qf6ws8Fz+8nDF2b40RgLu j8qwfDySE0d1jaY1MOlbosluhaTD8Qge11B5EfByjbNNTX4C/GJFToN1Q9b7Gas4uDKN 0wfK1ERZndTWmwPSmc+YBVrtOkyLPkKYUXVhI0ZLyKwZbYyb2WjundPN9oxDxx/a7TsI endClu0csDou+ghl8pfdZNwN8KrhQWVKhBRfR4BLeSed9H5+yxVdJGdgKAeHo/yH0/A7 2AOdbgbor79UADjKooxtYYcVXjgX8DBY0QIt/KuIjfZfQsrcYR/Jp/JcMLAdJUjHZ1cs 4VfA== X-Gm-Message-State: AOUpUlGdZO/sh9gT7Iz8OfUEQIja5p4ap5qit7y76+75o2jp4oS5ty7D PNoh9bZbsXau7G0gQqYeG3O+6Hek/FyWbg== X-Google-Smtp-Source: AA+uWPznugaBCmOv3r+c9g6KLNa0E/T5PnC+cv8qH+PkQGcxqA1AyVrxl8nmQB8OskTTuiU9OWWHKg== X-Received: by 2002:a63:a053:: with SMTP id u19-v6mr28885573pgn.394.1535035048245; Thu, 23 Aug 2018 07:37:28 -0700 (PDT) Received: from raichu (toroon0560w-lp130-09-70-52-224-239.dsl.bell.ca. [70.52.224.239]) by smtp.gmail.com with ESMTPSA id o3-v6sm5099262pgv.53.2018.08.23.07.37.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Aug 2018 07:37:27 -0700 (PDT) Sender: Mark Johnston Date: Thu, 23 Aug 2018 10:37:24 -0400 From: Mark Johnston To: Hans Petter Selasky Cc: Sebastian Huber , Eugene Grosbein , FreeBSD Subject: Re: epoch(9) background information? Message-ID: <20180823143724.GB68810@raichu> References: <3bfedcc3-0dae-7979-2bd4-da83f2c67e87@embedded-brains.de> <5B7E7804.4030907@grosbein.net> <978ae736-89b9-6d83-e2a1-d2834ca8ae55@embedded-brains.de> <90e16238-6e4d-5d3d-499d-2a19a49be78c@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90e16238-6e4d-5d3d-499d-2a19a49be78c@selasky.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 14:37:30 -0000 On Thu, Aug 23, 2018 at 12:27:12PM +0200, Hans Petter Selasky wrote: > On 8/23/18 11:28 AM, Sebastian Huber wrote: > > On 23/08/18 11:01, Eugene Grosbein wrote: > >> On 23.08.2018 15:39, Sebastian Huber wrote: > >> > >>> We used the FreeBSD network stack also on low-end targets > >>> (uni-processor) such as MCF548x ColdFire, Atmel SAM V71, SPARC LEON, > >>> etc. in current production environments (not legacy systems). The > >>> introduction of lock-free data structures (Concurrency Kit) and this > >>> epoch memory reclamation makes little sense on these targets (at least > >>> from my point of view). However, FreeBSD has still the SMP configuration > >>> option (sys/conf/options) which suggests that SMP is optional. Is a > >>> uni-processor system something which is considered by the FreeBSD > >>> community as a thing worth supporting or can I expect that this is an > >>> exotic environment which will get less and less well supported in the > >>> future? I just need some guidance so that I can better plan for future > >>> FreeBSD baseline updates. > >> FreeBSD as virtualized uniprocessor guest should be supported at full > >> scale, > >> as well as embedded applications using single core x86 and non-x86 CPUs. > > > > If something should be supported, then there must be also someone who > > ensures that this is actually the case. I don't know the FreeBSD > > community good enough to judge if there is sufficient > > manpower/funding/interest for a well supported uni-processor FreeBSD. > > From the commits it is clear that FreeBSD receives a lot of attention > > from CDN providers such as Netflix and Limelight Networks. They probably > > don't care about uni-processor system support at all. The use of > > lock-free data structures (Concurrency Kit) and the epoch memory > > reclamation are now a mandatory infrastructure. There is no FreeBSD > > configuration option to avoid this. > > > > The Concurrency Kit in sys/contrib/ck has no explicit support for the > > FreeBSD RISC-V and MIPS architectures. So, I guess the fall-back > > sys/contrib/ck/include/gcc/ck_pr.h is used. The atomic support in > > sys/contrib/ck partially duplicates/extends the general atomic support > > of the FreeBSD kernel ATOMIC(9). To me it is a bit unclear what will be > > the future direction in the FreeBSD kernel with respect to lock-free > > data structures. > > > > Hi Sebastian, > > Do you have something like critical_enter() to disable pre-emption in > your OS? If you don't need to support SMP, the CPU pinning in the EPOCH > can be replaced by a critial_enter() / critial_exit() pair. Threads in preemptible epoch sections are allowed to acquire locks, so critical_enter()/exit() isn't a suitable replacement for epoch sections. I think a fallback implementation could be written without CK for the !SMP case, but it would require some work.