All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Starikovskiy <aystarik@gmail.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Alexey Starikovskiy <astarikovskiy@suse.de>,
	Lin Ming <ming.m.lin@intel.com>, Xiaotian Feng <dfeng@redhat.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Len Brown <lenb@kernel.org>,
	"Moore, Robert" <robert.moore@intel.com>
Subject: Re: [PATCH -V2] acpi: don't cond_resched if irq is disabled
Date: Fri, 11 Dec 2009 19:25:25 +0300	[thread overview]
Message-ID: <4B227275.5010201@gmail.com> (raw)
In-Reply-To: <20091211161549.GA15760@elf.ucw.cz>

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-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Alexey Starikovskiy <aystarik@gmail.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Alexey Starikovskiy <astarikovskiy@suse.de>,
	Lin Ming <ming.m.lin@intel.com>, Xiaotian Feng <dfeng@redhat.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Len Brown <lenb@kernel.org>,
	"Moore, Robert" <robert.moore@intel.com>
Subject: Re: [PATCH -V2] acpi: don't cond_resched if irq is disabled
Date: Fri, 11 Dec 2009 19:25:25 +0300	[thread overview]
Message-ID: <4B227275.5010201@gmail.com> (raw)
In-Reply-To: <20091211161549.GA15760@elf.ucw.cz>

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.

  reply	other threads:[~2009-12-11 16:25 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-04  4:26 [PATCH] ACPICA: don't cond_resched() when irq_disabled or in_atomic Xiaotian Feng
2009-12-04  5:36 ` Zhang Rui
2009-12-04  5:38   ` Zhang Rui
2009-12-04  6:50 ` Justin Mattock
2009-12-04  6:50   ` Justin Mattock
2009-12-04  7:05   ` Danny Feng
2009-12-04  7:27     ` Justin P. Mattock
2009-12-09  1:54       ` Xiaotian Feng
2009-12-10 10:09 ` Pavel Machek
2009-12-10 11:56   ` [PATCH -V2] acpi: don't cond_resched if irq is disabled Xiaotian Feng
2009-12-10 12:21     ` Alexey Starikovskiy
2009-12-10 12:21       ` Alexey Starikovskiy
2009-12-11  5:46       ` Lin Ming
2009-12-11  5:46         ` Lin Ming
2009-12-11 11:48         ` Alexey Starikovskiy
2009-12-11 11:48           ` Alexey Starikovskiy
2009-12-11 16:15           ` Pavel Machek
2009-12-11 16:25             ` Alexey Starikovskiy [this message]
2009-12-11 16:25               ` Alexey Starikovskiy
2009-12-11 17:34               ` Pavel Machek
2009-12-28  6:02                 ` Xiaotian Feng
2009-12-28 11:12                   ` Alexey Starikovskiy
2009-12-28 11:12                     ` Alexey Starikovskiy
2010-01-16  6:44                     ` Len Brown
2009-12-10 17:58   ` [PATCH] ACPICA: don't cond_resched() when irq_disabled or in_atomic Alexey Starikovskiy
2009-12-10 17:58     ` Alexey Starikovskiy
2009-12-10 18:18     ` Pavel Machek
2009-12-10 18:37       ` Alexey Starikovskiy
2009-12-10 18:37         ` Alexey Starikovskiy
2009-12-10 22:46         ` Justin P. Mattock
2009-12-10 22:46           ` Justin P. Mattock
2009-12-10 22:54           ` Moore, Robert
2009-12-10 22:54             ` Moore, Robert
2010-01-16  6:46             ` Len Brown
2009-12-11 17:33         ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B227275.5010201@gmail.com \
    --to=aystarik@gmail.com \
    --cc=astarikovskiy@suse.de \
    --cc=dfeng@redhat.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.m.lin@intel.com \
    --cc=pavel@ucw.cz \
    --cc=robert.moore@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.