Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp1095358ybg; Wed, 29 Jul 2020 05:52:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyYiAZk7crJJTwX4mbGSAl/aczpB9VQzVJ8/Ao/s6T8NKnrfaa4nw4SOgDuhLmKw6czmTOI X-Received: by 2002:a17:906:454e:: with SMTP id s14mr17960127ejq.147.1596027130178; Wed, 29 Jul 2020 05:52:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596027130; cv=none; d=google.com; s=arc-20160816; b=NSuLp5zBvS/Zcmf0y1zNRcbRxqVZBkXFP2a1iEmC5UNkKXKsSKBcz01kqdCgXExzIu U7lZ16hIngwIbY8m/RRh0RN+kbgB6TtpVZfPe/fgq/SYUcHsqtAX7s/hSRJeCUguLMUs 0Xoq9/1MZ3cT6fMEZwK3eAwhop6YZDO9oM1Ev4QC2VEp2G/XnV1t3viqNRLgtS/+OPQN 0s9EZ/2hxUaV/7iKkvAwXnKNP1dxvk3oU3rEpSHkM4SjEBIRE83HptaEJReimE4h5Y2n An6XPIK7nfgRPUN+QwMfgk4bVnX3zUQGV0kICIuf9eEon5NJizWh5aLR/zTzJUlPLu0Z l3ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=8IkNVCqZ8o62b1wJv+jsExiR+ROIhSQLBLR6U6CMFFk=; b=ZhTH3ZJepjM2kO6jCVh90zOU4yWiCn7GKBUiv52zShj0MRS6VwEXw6NQgkKYgbZiG1 Hm6efJ8Hxf9ZqY6HJP0NdirtvTz+FACkjn244rJ0VaZXF7XNP2HlF9oBXNks6+2Ut/NI ldfyXxY2QpiIfHACkB52T/Zmi6xxfZK+2P+hbOAdMGWrs0s97MwZzuBtkVN0ELX88A0j E7dvNGvG4xhfoAGhrRIP7wvt7kw8dy9jHGmwEEWCxZ0p8ZBS+YAU+flozmaSYC1rZn8J QnsAUZo+Py/1g/0WrfFEjlKEkP12m2/TuROG8b8KGEhCYe3PAL/bb1YnkF4yY3OOIzuE OlpQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XNQAOjeJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h4si1001714eje.121.2020.07.29.05.51.46; Wed, 29 Jul 2020 05:52:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XNQAOjeJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726877AbgG2Mv0 (ORCPT + 99 others); Wed, 29 Jul 2020 08:51:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44506 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726353AbgG2MvZ (ORCPT ); Wed, 29 Jul 2020 08:51:25 -0400 Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23681C061794 for ; Wed, 29 Jul 2020 05:51:24 -0700 (PDT) Received: by mail-ot1-x342.google.com with SMTP id l27so10234292oti.3 for ; Wed, 29 Jul 2020 05:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8IkNVCqZ8o62b1wJv+jsExiR+ROIhSQLBLR6U6CMFFk=; b=XNQAOjeJVIaf7vQSbZVECk3+qvpDSBC2IbcvR41S6kgx6tK2ZHaWVh4I9Uib0hKOM3 LsMk8XDRlA1JixiXG6O9LfAIbIYXGeUG8iGj0xe6m04xWNDxaFFb+A0qz75B7TrKfSBs fL0PSmvWUxtQWM84U/Av8QjIzx+lbJ6vT98DaIRUML53AfyxQBgzfiJ7riUjscEmZTg2 0nmlV3fGjOZZVlYFSQjs/dh7YtVQE1ih/t2wpBpJBC0Tr31Kj+GhPtmQQICmgxq67lOc Jwk4oeUkmYA4P9u7nIM2dVZdqqQv7yPPsmHa9t6ANVGTVwm9pk6cGc1Ws5lmmZLb2Bd+ MAUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8IkNVCqZ8o62b1wJv+jsExiR+ROIhSQLBLR6U6CMFFk=; b=k2TRiFWqiMoBQtmpvD92YR7oZV6yuc2jduLfdRRxUkHcK0H2+QedKDJ+XZrMwXumgU 073fTF/Qu1oWWQvo5lURCFF6ZNLQZbbvHWbRRaxEp9Udn5Qh3upI/XLJm1iKo+z0boQN C5rYFxTRLwBcXG/z/UqhE1IwVMvhZn1Sx6dmXsdPbZqyV5z78VgQnGawKRKeUdC8vO8g 5oHLxMnrR4DKs7wACLr8LRLExPteIV2ocZVyQQiOLQFoaApju/lyCfYS0zlivhcCtbTz iSupR5jAPC9VFjEqz5Q44i6KDi0WUyrlS0fC//b6S7UjBpn4p3yoEUJweaHeDO9gqi3D mYZQ== X-Gm-Message-State: AOAM530yYIGTf51oq/gjwPW6CLpOjSYcn51cbE1FFGOm5n8UsGLCVXtc syfFpCIVZD3TvMcMRFKMrGi4G98itc+Ch54EKAs= X-Received: by 2002:a9d:25:: with SMTP id 34mr2147274ota.343.1596027083558; Wed, 29 Jul 2020 05:51:23 -0700 (PDT) MIME-Version: 1.0 References: <1595601083-10183-1-git-send-email-qianjun.kernel@gmail.com> <87sgddaru7.fsf@nanos.tec.linutronix.de> <87v9i6a53n.fsf@nanos.tec.linutronix.de> In-Reply-To: <87v9i6a53n.fsf@nanos.tec.linutronix.de> From: jun qian Date: Wed, 29 Jul 2020 20:51:12 +0800 Message-ID: Subject: Re: [PATCH V4] Softirq:avoid large sched delay from the pending softirqs To: Thomas Gleixner Cc: peterz@infradead.org, will@kernel.org, luto@kernel.org, linux-kernel@vger.kernel.org, Yafang Shao , Uladzislau Rezki Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 29, 2020 at 8:16 PM Thomas Gleixner wrote: > > Qian, > > jun qian writes: > > On Mon, Jul 27, 2020 at 11:41 PM Thomas Gleixner wrote: > >> > + or_softirq_pending(pending << (vec_nr + 1)); > >> > >> To or the value interrupts need to be disabled because otherwise you can > >> lose a bit when an interrupt happens in the middle of the RMW operation > >> and raises a softirq which is not in @pending and not in the per CPU > >> local softirq pending storage. > >> > > I can't understand the problem described above, could you explain in > > detail. > > Oring a value to a memory location is a Read Modify Write (RMW) > operation. > > x |= a; > > translates to pseudo code: > > R1 = x // Load content of memory location x into register R1 > R1 |= a // Or value a on R1 > x = R1 // Write back result > > So assume: > > x = 0 > a = 1 > > R1 = x --> R1 == 0 > R1 |= a --> R1 == 1 > > interrupt sets bit 1 in x --> x == 0x02 > > x = R1 --> x == 1 > > So you lost the set bit 1, right? Not really what you want. > wow, thanks a lot, i got it. > >> There is another problem. Assume bit 0 and 1 are pending when the > >> processing starts. Now it breaks out after bit 0 has been handled and > >> stores back bit 1 as pending. Before ksoftirqd runs bit 0 gets raised > >> again. ksoftirqd runs and handles bit 0, which takes more than the > >> timeout. As a result the bit 0 processing can starve all other softirqs. > >> > > May I use a percpu val to record the order of processing softirq, by the order > > val, when it is in ksoftirqd we can process the pending softirq in order. In the > > scenario you described above, before ksoftirqd runs, bit 0 gets raised again, > > ksoftirqd runs and handles bit 1 by the percpu val. just like a ring. > > Yes, you need something to save information about the not-processed > bits. Keeping track of which bit to process next works, but whether > that's going to result in efficient and simple code is a different > question. > ok, i will modify it in the next version. > Thanks, > > tglx >