From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161082AbWBAPNK (ORCPT ); Wed, 1 Feb 2006 10:13:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161081AbWBAPNK (ORCPT ); Wed, 1 Feb 2006 10:13:10 -0500 Received: from mx3.mail.elte.hu ([157.181.1.138]:58241 "EHLO mx3.mail.elte.hu") by vger.kernel.org with ESMTP id S1161080AbWBAPNI (ORCPT ); Wed, 1 Feb 2006 10:13:08 -0500 Date: Wed, 1 Feb 2006 16:11:37 +0100 From: Ingo Molnar To: Nick Piggin Cc: Steven Rostedt , Peter Williams , Thomas Gleixner , Andrew Morton , LKML Subject: Re: [PATCH] Avoid moving tasks when a schedule can be made. Message-ID: <20060201151137.GA14794@elte.hu> References: <1138797874.7088.44.camel@localhost.localdomain> <43E0B24E.8080508@yahoo.com.au> <43E0B342.6090700@yahoo.com.au> <20060201132054.GA31156@elte.hu> <43E0BBEC.3020209@yahoo.com.au> <43E0BDA3.8040003@yahoo.com.au> <20060201141248.GA6277@elte.hu> <43E0C4CF.8090501@yahoo.com.au> <20060201143727.GA9915@elte.hu> <43E0CBBC.2000002@yahoo.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43E0CBBC.2000002@yahoo.com.au> User-Agent: Mutt/1.4.2.1i X-ELTE-SpamScore: 0.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=0.0 required=5.9 tests=AWL autolearn=no SpamAssassin version=3.0.3 0.0 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org * Nick Piggin wrote: > Ingo Molnar wrote: > >* Nick Piggin wrote: > > > > > >>What I am talking about is when you want a task to have the highest > >>possible scheduling priority and you'd like to guarantee that it is > >>not interrupted for more than Xus, including scheduling latency. > > > > > >this is not a big issue in practice, because it's very hard to saturate > >current x86 systems running the -rt kernel with pure IRQ load. The APIC > >messages all have a natural latency, which serves as a throttler. > > > > Either way, you don't measure it. Doesn't matter. As I said, off > topic. (sure we are measuring such effects too - our current worst-case latency paths are related to two-irqs-after-each-other scenarios.) > >> > >>Then it is a fine hack for the RT kernel (or at least an improved, > >>batched version of the patch). No arguments from me. > > > > > >no, it is also fine for the mainline scheduler, as long as the patch is > >clean and does the obviously right thing [which the current patch doesnt > >offer]. A 1+ msec latency with irqs off is nothing to sniff at. Trying > > If it were generated by some real workload that cares, then I would care. well, you might not care, but i do. It's up to you what you care about, but right now the scheduler policy is that we do care about latencies. Yes, it's obviously all subject to common sense, and if something triggers in a rare and extreme workload then any change related to it has a _much_ higher barrier of acceptance than a common codepath. But your blanket dismissal of this whole subject based on the rarity of the workload is just plain wrong. > >to argue that 'you can get the same by using rwsems so why should we > >bother' is pretty lame: rwsems are rare and arguably broken in > >behavior, and i'd not say the same about the scheduler (just yet :-). > > I don't think it is lame at all. They're fairly important in use in > mmap_sem that I know of. And I have seen workloads where the up_write > path gets really expensive (arguably more relevant ones than > hackbench). they are broken e.g. in that they are mass-waking all the readers with interrupts disabled. At a minimum rwsems should be declared irq-unsafe (like mutexes), as all the substantial uses are in process-context codepaths anyway. I'll revisit rwsems once the current mutex work is done. Ingo