From owner-svn-src-head@freebsd.org Wed Nov 29 16:59:35 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97D86E5DB62; Wed, 29 Nov 2017 16:59:35 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6388C7BCBA; Wed, 29 Nov 2017 16:59:35 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-it0-x241.google.com with SMTP id d16so4948823itj.1; Wed, 29 Nov 2017 08:59:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Og1mbLFppyTW07t02QgexPOLQmWA25fSM/E3PZoBh4A=; b=AtOaxpV8iC2ufpdtBMZlb62+oRsZk22mjZnAITxQz1SIdxuDaIQgXSTC2d2yHuPTy0 fOGjoIG0ZTghqf0BbxPaIm8rx0sliuQAuxfb9Yx3pLDJFeIlrr2Y5Er8SVmah4meR7dd xBjcloHy5N3iwFFeVLrk5CV0o6UltK+PIHNqM3sa8htN2VpvlLWVex2qluRNLuDfKK2m e/aR6pshEuO8+xnsQ0olGaqdp9UpP8V3F25gyYUz0YvJi/K33oWuXtsl2H9XOr/JuRpr n4/Kv9ZkWhX9OI3D15YGXTvdhuw+mo5bcvkFo2Kg59D5VrEUD0NkAtAP4AVQJjIhbgUf 5mSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Og1mbLFppyTW07t02QgexPOLQmWA25fSM/E3PZoBh4A=; b=leUxbpOaoOmq9JxvgGgyFjFH7mKlVWfSfOfxD7qRKdakt/WJnj5vNU1a3mHbq8NhqH AIlzkmFNVdy8an19VU1JBAiXBM+GGKaMv2mF8h8feNxvKhwFs9fK27NB1n/M5Y+ja3cQ Hyag8Atmjd9tSX6vZoKZY2q3cogklHg+EElJDLaiTmowCob8MBuWI6F6OmiKTSaal2wO hKZgvRMeIGAqOYelRqEqumqLf3yYDd388s+qY0Lxs7e98UlYINqNsChq2wYRRYjyFdb6 fzGZxWIVYQPTs0GuJ/V7rKbm1x3YJlLsLNRkYvlpQkX/3XxaXm+ypCkIm4ZExBtlDrIo P1qw== X-Gm-Message-State: AJaThX736tBmOGqfcWHOLhzD/ax7pR6yPRN0qi1nad7O2RpktMQ7yz2y i3ygThA+oQC7elLopR0yLG2DKGBMpR4oQ2uZ+kY= X-Google-Smtp-Source: AGs4zMaV7MafvqkG1XkinQlLtK9c7jqZJsrVTHpzAct/QC9vIjd1ezXFTJ7O0jCaQhh3i0vfj7DaxTFm27p2rUg6od0= X-Received: by 10.36.245.200 with SMTP id k191mr8049256ith.20.1511974774563; Wed, 29 Nov 2017 08:59:34 -0800 (PST) MIME-Version: 1.0 Sender: chmeeedalf@gmail.com Received: by 10.79.78.207 with HTTP; Wed, 29 Nov 2017 08:59:34 -0800 (PST) In-Reply-To: <20171129161356.GA2272@kib.kiev.ua> References: <201711252341.vAPNf5Qx001464@repo.freebsd.org> <14322447.103fKFTi3y@ralph.baldwin.cx> <3fc45d5f-22b9-0562-278b-c515e36f48e7@freebsd.org> <14058479.lc6xlYgyBM@ralph.baldwin.cx> <2e752d6a-d34a-dde0-acea-fdbf8bebea51@selasky.org> <20171129161356.GA2272@kib.kiev.ua> From: Justin Hibbits Date: Wed, 29 Nov 2017 10:59:34 -0600 X-Google-Sender-Auth: GjREahYCMJB1jhZEcmdezfMzWB8 Message-ID: Subject: Re: svn commit: r326218 - head/sys/kern To: Konstantin Belousov Cc: Hans Petter Selasky , John Baldwin , Nathan Whitehorn , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" , Konstantin Belousov , "O. Hartmann" , KrishnamRaju ErapaRaju Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Wed, 29 Nov 2017 17:11:43 +0000 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 16:59:35 -0000 On Wed, Nov 29, 2017 at 10:13 AM, Konstantin Belousov wrote: > On Wed, Nov 29, 2017 at 04:33:50PM +0100, Hans Petter Selasky wrote: >> Hi Nathan, >> >> The chunk below causes sched_pin() to stop working and should be removed >> from your commit ??!! >> >> It probably explains the hangs seen recently reported by various brave >> people running 12-current :-) >> >> Specifically I see threads migrating between CPUs when td->td_pinned > 0 >> using the LinuxKPI RCU API, which in turn leads to a hang when trying to >> synchronize RCU. >> >> --HPS >> >> diff --git a/sys/kern/sched_ule.c b/sys/kern/sched_ule.c >> index 5c8bae5afa1..bd4b505f6c3 100644 >> --- a/sys/kern/sched_ule.c >> +++ b/sys/kern/sched_ule.c >> @@ -2453,7 +2453,7 @@ sched_add(struct thread *td, int flags) >> * Pick the destination cpu and if it isn't ours transfer to the >> * target cpu. >> */ >> - td_get_sched(td)->ts_cpu = curcpu; /* Pick something valid to >> start */ >> +// td_get_sched(td)->ts_cpu = curcpu; /* Pick something valid to >> start */ >> cpu = sched_pickcpu(td, flags); >> tdq = sched_setcpu(td, cpu, flags); >> tdq_add(tdq, td, flags); > > To clarify. It seems that this change breaks sched_bind(). > > It might be that LinuxKPI does use sched_pin() in somewhat questionable > way. Namely, the code puts the thread off the CPU (e.g. by taking a > lock). Then, is it guaranteed that the pinned thread returns to the same > cpu after sched_add() ? > > I think that the second behaviour is not guaranteed, but it might > happens by the way the things are arranged. If guaranteed, then the > sched_pin() breakage is same as for sched_bind(). > I see the same breakage on PowerPC with the dtsec(4) driver, which pins interrupts to CPUs, now causing interrupts to migrate to cores without the matching portal mapping. - Justin