All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@tv-sign.ru>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] big IRQ lock removal, 2.5.27-G0
Date: Wed, 24 Jul 2002 03:40:53 +0400	[thread overview]
Message-ID: <3D3DE984.A6FEA4CB@tv-sign.ru> (raw)

Hello.

I can't understand the preempt_count() check in irq_exit()
and local_bh_enable(). Did you meant irq_count() instead?
I beleive preempt_disable() should not disable soft interrupts.

In local_bh_enable() it is probably unneeded at all, because
nested local_bh_disable() is rare (i think), and do_softirq()
checks in_interrupt().

Now suppose preempt_count() & PREEMPT_MASK == 0.

Then local_bh_enable() has a small preemptible window between
__local_bh_enable() and do_softirq()->local_irq_save(flags).
It is only latency problem.

But in irq_exit() case interrupt context may be preempted
while doing wakeup_softirqd(cpu) after __local_bh_enable()
in do_softirq().

So i suggest something like this pseudo code:

__preempt_hack(offset)
{
        barrier();
        preempt_count() -= offset
#ifdef  CONFIG_PREEMPT
                        - 1
#endif
        ;
}

irq_exit()
{
        __preempt_hack(HARDIRQ_OFFSET);
        if (unlikely(!irq_count() &&
                        softirq_pending(smp_processor_id())))
                do_softirq();
        preempt_enable_no_resched();
}

local_bh_enable()
{
        __preempt_hack(SOFTIRQ_OFFSET);
        if (unlikely(!irq_count() &&
                        softirq_pending(smp_processor_id())))
                do_softirq();
        preempt_enable();
}

Or just add extra preempt_disable() in both functions to kill
terrible __preempt_hack().

Sorry, i have no remove-irqlock patches applied, so can't
suggest diff.

Oleg.

             reply	other threads:[~2002-07-23 23:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-23 23:40 Oleg Nesterov [this message]
2002-07-23 23:50 ` [patch] big IRQ lock removal, 2.5.27-G0 Ingo Molnar
2002-07-23 23:54   ` Ingo Molnar
2002-07-24  1:00   ` Oleg Nesterov
2002-07-24  7:19     ` Ingo Molnar
2002-07-24  3:07   ` Oleg Nesterov
  -- strict thread matches above, loose matches on Subject: below --
2002-07-23 16:26 Ingo Molnar

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=3D3DE984.A6FEA4CB@tv-sign.ru \
    --to=oleg@tv-sign.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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.