From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753850AbdCHRQ0 (ORCPT ); Wed, 8 Mar 2017 12:16:26 -0500 Received: from mail-wr0-f193.google.com ([209.85.128.193]:35742 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753768AbdCHRQY (ORCPT ); Wed, 8 Mar 2017 12:16:24 -0500 Date: Wed, 8 Mar 2017 18:16:19 +0100 From: Ingo Molnar To: Linus Torvalds Cc: Linux Kernel Mailing List , Peter Zijlstra , Thomas Gleixner , Andrew Morton Subject: Re: [RFC PATCH] sched/wait: Introduce new, more compact wait_event*() primitives Message-ID: <20170308171619.GA3301@gmail.com> References: <20170303013646.GA32094@gmail.com> <20170308083719.GA3251@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Linus Torvalds wrote: > On Wed, Mar 8, 2017 at 12:37 AM, Ingo Molnar wrote: > > > > The idea is to allow call sites to supply the 'condition' function as free-form C > > code, while pushing everything else into non-macro form: there's a 'struct > > wait_event_state' on stack, and a state machine. The waiting logic is converted > > from procedural form to a state machine, because we have to call out into the > > 'condition' code in different circumstances. > > Ok, I think the concept is fine, but you don't actually fix the > problem with the locked version that needs to unlock (with irq > versions etc) around the schedule. Indeed it doesn't, yet. > And using "bool" in a struct is disgusting and wrong, and hides the > fact that the compiler will just turn it into "char" (or even "int" > for platforms where "char'" is slow, like alpha). > > So it would be better with a "state" variable that just has fields, I suspect. > > .. and as mentioned, it doesn't actually fix the case that hit the > signal_pending() problem. > > Honestly, I think my "pass in a waiter function" model was both less > subtle and indirect, and more generic. True! > And we can actually *fix* the problem with it for 4.11, instead of > adding the stupid header file includes. Ok - I'm perfectly fine with your patch too, if you think it's v4.11 material! Thanks, Ingo