From: Valentine <vbarshak@ru.mvista.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: olof@lixom.net, linuxppc-dev@ozlabs.org, paulus@samba.org
Subject: Re: [PATCH v3] powerpc/ppc64: Use preempt_schedule_irq instead of preempt_schedule
Date: Thu, 29 Oct 2009 01:49:57 +0300 [thread overview]
Message-ID: <4AE8CA95.7060402@ru.mvista.com> (raw)
In-Reply-To: <1256765834.26770.6.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Thu, 2009-10-29 at 00:28 +0300, Valentine wrote:
>> Benjamin Herrenschmidt wrote:
>>> On Wed, 2009-10-28 at 22:19 +0300, Valentine wrote:
>>>
>>>> I'm just not sure that we need to clear HARDIRQEN here, since we don't
>>>> really hard-disable the the interrupts.
>>> We do, or rather, we come in with the interrupts hard disabled, no ?
>> Yes, looks like the interrupts are disabled at this point (before
>> preempt_schedule_irq) most of the times, but we don't hard-disable them
>> here. We just soft-disable them to make preempt_schedule_irq happy. Even
>> if an interrupt fires, it will be hard-disabled and the hardirq flag
>> will be cleared by the exception handler right away. I just think that
>> there's no need to clear hardirq flag if we don't clear MSR_EE.
>
> My point is that MSR_EE _is_ already clear... isn't it ?
Yes, the MSR_EE is cleared before we jump to do_work. I'm OK with
clearing the hardirqenable flag. I just assumed that the hardirq flag
was supposed to reflect the MSR_EE state, so it looked a bit odd
clearing the MSR_EE at one place and then reflecting the change at another.
Anyway, the patch works fine.
Thanks,
Val.
So either we
> set it back, or we clear HARDIRQEN to reflect it. It will be re-enable
> as soon as preempt_schedule_irq() calls local_irq_enable() which is soon
> enough anyways.
>
> Also that avoids perf interrupt sneaking in since those act as NMIs in
> that regard and -will- get in even when soft disabled.
>
> Cheers,
> Ben.
>
>> Thanks,
>> Val.
>>> Ben.
>>>
>>>> Thanks,
>>>> Val.
>>>>
>>>>> + TRACE_DISABLE_INTS
>>>>> +
>>>>> + /* Call the scheduler with soft IRQs off */
>>>>> +1: bl .preempt_schedule_irq
>>>>> +
>>>>> + /* Hard-disable interrupts again (and update PACA) */
>>>>> #ifdef CONFIG_PPC_BOOK3E
>>>>> - wrteei 1
>>>>> - bl .preempt_schedule
>>>>> wrteei 0
>>>>> #else
>>>>> - ori r10,r10,MSR_EE
>>>>> - mtmsrd r10,1 /* reenable interrupts */
>>>>> - bl .preempt_schedule
>>>>> mfmsr r10
>>>>> - clrrdi r9,r1,THREAD_SHIFT
>>>>> - rldicl r10,r10,48,1 /* disable interrupts again */
>>>>> + rldicl r10,r10,48,1
>>>>> rotldi r10,r10,16
>>>>> mtmsrd r10,1
>>>>> #endif /* CONFIG_PPC_BOOK3E */
>>>>> + li r0,0
>>>>> + stb r0,PACAHARDIRQEN(r13)
>>>>> +
>>>>> + /* Re-test flags and eventually loop */
>>>>> + clrrdi r9,r1,THREAD_SHIFT
>>>>> ld r4,TI_FLAGS(r9)
>>>>> andi. r0,r4,_TIF_NEED_RESCHED
>>>>> bne 1b
>>>>> b restore
>>>>>
>>>>> user_work:
>>>>> -#endif
>>>>> +#endif /* CONFIG_PREEMPT */
>>>>> +
>>>>> /* Enable interrupts */
>>>>> #ifdef CONFIG_PPC_BOOK3E
>>>>> wrteei 1
>>>
>
>
next prev parent reply other threads:[~2009-10-28 22:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-19 18:28 [PATCH] [RFC] PowerPC64: Use preempt_schedule_irq instead of preempt_schedule when returning from exceptions Valentine Barshak
2009-10-26 23:55 ` Benjamin Herrenschmidt
2009-10-27 5:41 ` [PATCH v3] powerpc/ppc64: Use preempt_schedule_irq instead of preempt_schedule Benjamin Herrenschmidt
2009-10-28 19:19 ` Valentine
2009-10-28 20:30 ` Benjamin Herrenschmidt
2009-10-28 21:28 ` Valentine
2009-10-28 21:37 ` Benjamin Herrenschmidt
2009-10-28 22:49 ` Valentine [this message]
2009-10-29 0:49 ` Benjamin Herrenschmidt
2009-11-06 22:38 ` Valentine
2009-11-06 22:49 ` Benjamin Herrenschmidt
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=4AE8CA95.7060402@ru.mvista.com \
--to=vbarshak@ru.mvista.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=olof@lixom.net \
--cc=paulus@samba.org \
/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.