Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750902AbWHKIqU (ORCPT ); Fri, 11 Aug 2006 04:46:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750903AbWHKIqU (ORCPT ); Fri, 11 Aug 2006 04:46:20 -0400 Received: from adsl-69-232-92-238.dsl.sndg02.pacbell.net ([69.232.92.238]:18310 "EHLO gnuppy.monkey.org") by vger.kernel.org with ESMTP id S1750897AbWHKIqT (ORCPT ); Fri, 11 Aug 2006 04:46:19 -0400 Date: Fri, 11 Aug 2006 01:46:03 -0700 To: Esben Nielsen Cc: Steven Rostedt , Robert Crocombe , linux-kernel@vger.kernel.org, Ingo Molnar , Thomas Gleixner , Darren Hart , "Bill Huey (hui)" Subject: Re: [Patch] restore the RCU callback to defer put_task_struct() Re: Problems with 2.6.17-rt8 Message-ID: <20060811084603.GA27068@gnuppy.monkey.org> References: <1154541079.25723.8.camel@localhost.localdomain> <1154615261.32264.6.camel@localhost.localdomain> <20060808025615.GA20364@gnuppy.monkey.org> <20060808030524.GA20530@gnuppy.monkey.org> <20060810021835.GB12769@gnuppy.monkey.org> <20060811010646.GA24434@gnuppy.monkey.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 From: Bill Huey (hui) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1591 Lines: 35 On Fri, Aug 11, 2006 at 10:16:56AM +0200, Esben Nielsen wrote: > On Thu, 10 Aug 2006, Bill Huey wrote: ... > >This extends the mmdrop logic with desched_thread() to also handle > >free_task() requests as well. I believe this address your concerns and > >I'm open to review of this patch. > Without applying the patch and only skimming it it looks like what Paul > and I concluded :-) > > But is there really no generic way of defering this kind of thing? It > looks like a hell of a lot work where a kind of "message" infrastructure > could have solved it in a few lines. You can composite it out of a generic kernel APIs to fake it or special case these things so it behaves like a message. Doing it this way also cleaned up the code a bit. Messaging also wouldn't have directly solved the per-CPU aspects of this reaping, so this was the right facility to use. The only question left in my mind is the proper choice of priority for that thread. Another note, the schedule() path is shorten by this as well since this deallocation and reaping stuff (calling to the mm system) was done with preemption turned off and inline to the child itself exiting. This patch should help shorted the maximal schedule path. It's one of the last remining long paths like this in the kernel. It seems to be an all around win if I'm not mistaken. bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/