[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B223185.80202@suse.de>
Date: Fri, 11 Dec 2009 14:48:21 +0300
From: Alexey Starikovskiy <astarikovskiy@...e.de>
To: Lin Ming <ming.m.lin@...el.com>
CC: Xiaotian Feng <dfeng@...hat.com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Len Brown <lenb@...nel.org>,
"Moore, Robert" <robert.moore@...el.com>,
Pavel Machek <pavel@....cz>
Subject: Re: [PATCH -V2] acpi: don't cond_resched if irq is disabled
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
>
Regards,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists