Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752813AbdHOXug (ORCPT ); Tue, 15 Aug 2017 19:50:36 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:36848 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751565AbdHOXuf (ORCPT ); Tue, 15 Aug 2017 19:50:35 -0400 MIME-Version: 1.0 In-Reply-To: References: <84c7f26182b7f4723c0fe3b34ba912a9de92b8b7.1502758114.git.tim.c.chen@linux.intel.com> <20170815022743.GB28715@tassilo.jf.intel.com> <20170815031524.GC28715@tassilo.jf.intel.com> <20170815224728.GA1373@linux-80c1.suse> From: Linus Torvalds Date: Tue, 15 Aug 2017 16:50:34 -0700 X-Google-Sender-Auth: 0XG-QBLU_8OsUkMIDXV4g6MUbZ4 Message-ID: Subject: Re: [PATCH 1/2] sched/wait: Break up long wake list walk To: Linus Torvalds , Andi Kleen , 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: 1692 Lines: 42 On Tue, Aug 15, 2017 at 3:57 PM, Linus Torvalds wrote: > > Oh, and the page wait-queue really needs that key argument too, which > is another thing that swait queue code got rid of in the name of > simplicity. Actually, it gets worse. Because the page wait queues are hashed, it's not an all-or-nothing thing even for the non-exclusive cases, and it's not a "wake up first entry" for the exclusive case. Both have to be conditional on the wait entry actually matching the page and bit in question. So no way to use swait, or any of the lockless queuing code in general (so we can't do some clever private wait-list using llist.h either). End result: it looks like you fairly fundamentally do need to use a lock over the whole list traversal (like the standard wait-queues), and then add a cursor entry like Tim's patch if dropping the lock in the middle. Anyway, looking at the old code, we *used* to limit the page wait hash table to 4k entries, and we used to have one hash table per memory zone. The per-zone thing didn't work at all for the generic bit-waitqueues, because of how people used them on virtual addresses on the stack. But it *could* work for the page waitqueues, which are now a totally separate entity, and is obviously always physically addressed (since the indexing is by "struct page" pointer), and doesn't have that issue. So I guess we could re-introduce the notion of per-zone page waitqueue hash tables. It was disgusting to allocate and free though (and hooked into the memory hotplug code). So I'd still hope that we can instead just have one larger hash table, and that is sufficient for the problem. Linus