Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753550AbZLKQZ2 (ORCPT ); Fri, 11 Dec 2009 11:25:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752023AbZLKQZX (ORCPT ); Fri, 11 Dec 2009 11:25:23 -0500 Received: from mail-bw0-f227.google.com ([209.85.218.227]:46976 "EHLO mail-bw0-f227.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751365AbZLKQZW (ORCPT ); Fri, 11 Dec 2009 11:25:22 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=kElZdmSw0LEPzQ9YanbFHGQIG6r3L7I3ifOf4Bo56yeZ6m8eJi7XMGdQUnR5HrBPqg 9o6Hedz3H+bgmcxygoPz5dC7urghQKRRFf+aHWK+eZWSjQkhLIu/Cm5WswIddCYGKnqz FDjkHIS3gyIUfo7nQ3wV3HGgBJ2CnFHZW9kKA= Message-ID: <4B227275.5010201@gmail.com> Date: Fri, 11 Dec 2009 19:25:25 +0300 From: Alexey Starikovskiy User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Pavel Machek CC: Alexey Starikovskiy , Lin Ming , Xiaotian Feng , "linux-acpi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Len Brown , "Moore, Robert" Subject: Re: [PATCH -V2] acpi: don't cond_resched if irq is disabled References: <20091210100907.GA2446@ucw.cz> <1260446205-16868-1-git-send-email-dfeng@redhat.com> <4B20E7B2.1010208@suse.de> <1260510373.10543.17.camel@minggr.sh.intel.com> <4B223185.80202@suse.de> <20091211161549.GA15760@elf.ucw.cz> In-Reply-To: <20091211161549.GA15760@elf.ucw.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1725 Lines: 48 Pavel Machek пишет: > On Fri 2009-12-11 14:48:21, Alexey Starikovskiy wrote: > >> Lin Ming ??????????: >> >>> On Thu, 2009-12-10 at 20:21 +0800, Alexey Starikovskiy wrote: >>> >>>> Hi Xiaotian, >>>> >>>> I think, this is another round of "armor vs. bullet" race... It will hold until >>>> might_sleep() logic changes again. >>>> >>>> Please consider using preemptible() -- IMHO this is the check we should perform >>>> in our case of voluntary preemption. >>>> >>> preemptible() may not work here because it always returns 0 for >>> non-preemptible kernel. >>> >> Right, and it means that this machine does not care about low latency that much. >> The reason we introduced the preemption point in the first place, was unacceptable latency >> due to very long AML methods on some machines. We don't need this preemption point for normal >> operation, this is exactly what voluntary preemption does -- allows those in hurry to pass by. >> If there are none, fine. >> >>> #ifdef CONFIG_PREEMPT >>> # define preemptible() (preempt_count() == 0 && !irqs_disabled()) >>> # define IRQ_EXIT_OFFSET (HARDIRQ_OFFSET-1) >>> #else >>> # define preemptible() 0 >>> # define IRQ_EXIT_OFFSET HARDIRQ_OFFSET >>> #endif >>> > > Well, normally we want low latency even for !CONFIG_PREEMPT kernels. > > Actually, explicit preemption points are NOPs for CONFIG_PREEMPT > kernels, right? > Pavel > Right. Do you have code? Thanks, Alex. -- 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/