From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756669Ab3IKFgH (ORCPT ); Wed, 11 Sep 2013 01:36:07 -0400 Received: from mail-ee0-f41.google.com ([74.125.83.41]:44872 "EHLO mail-ee0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754571Ab3IKFgF (ORCPT ); Wed, 11 Sep 2013 01:36:05 -0400 Date: Wed, 11 Sep 2013 07:36:01 +0200 From: Ingo Molnar To: Andi Kleen Cc: Andrew Morton , Geert Uytterhoeven , "linux-kernel@vger.kernel.org" , the arch/x86 maintainers , Peter Zijlstra , Andi Kleen Subject: Re: [PATCH 3/6] tree-sweep: Include linux/sched.h for might_sleep users Message-ID: <20130911053601.GA15110@gmail.com> References: <1376687844-19857-1-git-send-email-andi@firstfloor.org> <1376687844-19857-4-git-send-email-andi@firstfloor.org> <20130910165212.b95be29e2816dc69c909c058@linux-foundation.org> <20130911045109.GE18242@two.firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130911045109.GE18242@two.firstfloor.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andi Kleen wrote: > On Tue, Sep 10, 2013 at 04:52:12PM -0700, Andrew Morton wrote: > > On Sat, 31 Aug 2013 20:22:23 +0200 Geert Uytterhoeven wrote: > > > > > On Fri, Aug 16, 2013 at 11:17 PM, Andi Kleen wrote: > > > > might_sleep is moving from linux/kernel.h to linux/sched.h, so any users > > > > need to include linux/sched.h > > > > > > Really? is the worst choice w.r.t. include hell. > > > > Yes. Mechanically adding sched.h inclusions into .h files will cause > > problems. > > > > I've had decent success with this sort of thing by adding new, > > finer-grained headers. Maybe include/linux/might_sleep.h would be a > > good starting point to fix whatever it was that this fixed. > > Ok. I'll look into that and send new patches. > > Some of it may be obsolete with Peter's recent preempt work. The best order from a maintenance and merge POV would be to rebase your bits on top of Peter's preempt_count optimization work, which is the more comprehensive approach. That allows you to drop the obsolete bits, and wait for Peter to pick up your bits. The two interact so we want to handle them together in any case, in the scheduler tree. Thanks, Ingo