Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753193AbdHOD2V (ORCPT ); Mon, 14 Aug 2017 23:28:21 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:35928 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752960AbdHOD2U (ORCPT ); Mon, 14 Aug 2017 23:28:20 -0400 MIME-Version: 1.0 In-Reply-To: <20170815031524.GC28715@tassilo.jf.intel.com> References: <84c7f26182b7f4723c0fe3b34ba912a9de92b8b7.1502758114.git.tim.c.chen@linux.intel.com> <20170815022743.GB28715@tassilo.jf.intel.com> <20170815031524.GC28715@tassilo.jf.intel.com> From: Linus Torvalds Date: Mon, 14 Aug 2017 20:28:19 -0700 X-Google-Sender-Auth: Cy5XHnACBIMmkdUdgut0KDg_b5E Message-ID: Subject: Re: [PATCH 1/2] sched/wait: Break up long wake list walk To: Andi Kleen Cc: Tim Chen , Peter Zijlstra , Ingo Molnar , Kan Liang , Andrew Morton , Johannes Weiner , Jan Kara , linux-mm , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1509 Lines: 35 On Mon, Aug 14, 2017 at 8:15 PM, Andi Kleen wrote: > But what should we do when some other (non page) wait queue runs into the > same problem? Hopefully the same: root-cause it. Once you have a test-case, it should generally be fairly simple to do with profiles, just seeing who the caller is when ttwu() (or whatever it is that ends up being the most noticeable part of the wakeup chain) shows up very heavily. And I think that ends up being true whether the "break up long chains" patch goes in or not. Even if we end up allowing interrupts in the middle, a long wait-queue is a problem. I think the "break up long chains" thing may be the right thing against actual malicious attacks, but not for any actual real benchmark or load. I don't think we normally have cases of long wait-queues, though. At least not the kinds that cause problems. The real (and valid) thundering herd cases should already be using exclusive waiters that only wake up one process at a time. The page bit-waiting is hopefully special. As mentioned, we used to have some _really_ special code for it for other reasons, and I suspect you see this problem with them because we over-simplified it from being a per-zone dynamically sized one (where the per-zone thing caused both performance problems and actual bugs) to being that "static small array". So I think/hope that just re-introducing some dynamic sizing will help sufficiently, and that this really is an odd and unusual case. Linus