From: Alexey Starikovskiy <aystarik@gmail.com> To: Pavel Machek <pavel@ucw.cz> Cc: Xiaotian Feng <dfeng@redhat.com>, lenb@kernel.org, ming.m.lin@intel.com, robert.moore@intel.com, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ACPICA: don't cond_resched() when irq_disabled or in_atomic Date: Thu, 10 Dec 2009 21:37:59 +0300 [thread overview] Message-ID: <4B214007.2080409@gmail.com> (raw) In-Reply-To: <20091210181800.GM19454@elf.ucw.cz> Pavel Machek пишет: > On Thu 2009-12-10 20:58:45, Alexey Starikovskiy wrote: > >> Hi Pavel, >> >> Please elaborate... Your comments "ugly as hell" are too often to be >> specific... >> There is only one use of ACPI_PREEMPTION_POINT(), and it is in the >> ACPICA code, >> which we all agreed to keep OS independent, thus the need for #define. >> Do you see any other way to add preemption point without introducing >> Linux-specific >> code into ACPICA? >> > > I believe we want linux-specific code in acpica at this point. > > The point there we call cond_resched() in ACPICA is an interpreter parse loop. This parse loop may be executed from within atomic context and even with interrupts off. In this case, cond_resched() should not be called to not make might_sleep() guards angry. Please post the code, which will do the above and will not look "ugly as hell". I still don't follow your vague comments. > (Or maybe... I guess other systems have concept of preemption and not > all actions are permitted from all contexts, so maybe something like > that would be important for them, too?) > None of them cared about it up to this point. With the macro above we allowed them to follow Linux, but to go or not is their call. Regards, 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: Xiaotian Feng <dfeng@redhat.com>, lenb@kernel.org, ming.m.lin@intel.com, robert.moore@intel.com, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ACPICA: don't cond_resched() when irq_disabled or in_atomic Date: Thu, 10 Dec 2009 21:37:59 +0300 [thread overview] Message-ID: <4B214007.2080409@gmail.com> (raw) In-Reply-To: <20091210181800.GM19454@elf.ucw.cz> Pavel Machek пишет: > On Thu 2009-12-10 20:58:45, Alexey Starikovskiy wrote: > >> Hi Pavel, >> >> Please elaborate... Your comments "ugly as hell" are too often to be >> specific... >> There is only one use of ACPI_PREEMPTION_POINT(), and it is in the >> ACPICA code, >> which we all agreed to keep OS independent, thus the need for #define. >> Do you see any other way to add preemption point without introducing >> Linux-specific >> code into ACPICA? >> > > I believe we want linux-specific code in acpica at this point. > > The point there we call cond_resched() in ACPICA is an interpreter parse loop. This parse loop may be executed from within atomic context and even with interrupts off. In this case, cond_resched() should not be called to not make might_sleep() guards angry. Please post the code, which will do the above and will not look "ugly as hell". I still don't follow your vague comments. > (Or maybe... I guess other systems have concept of preemption and not > all actions are permitted from all contexts, so maybe something like > that would be important for them, too?) > None of them cared about it up to this point. With the macro above we allowed them to follow Linux, but to go or not is their call. Regards, Alex.
next prev parent reply other threads:[~2009-12-10 18:37 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 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 [this message] 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=4B214007.2080409@gmail.com \ --to=aystarik@gmail.com \ --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: linkBe 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.