All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: Huang Ying <ying.huang@intel.com>, Ingo Molnar <mingo@elte.hu>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] irq_work
Date: Fri, 25 Jun 2010 12:38:51 +0200	[thread overview]
Message-ID: <1277462331.32034.221.camel@twins> (raw)
In-Reply-To: <20100624123804.GK578@basil.fritz.box>

On Thu, 2010-06-24 at 14:38 +0200, Andi Kleen wrote:
>  The sleepable 
> soft irq would have avoided that (that's not a show stopper) 

I'm still not convinced sleepable softirq is a workable thing.

Softirqs:
  A) are non-preemptible
  B) are per-cpu because of A
  C) can be ran from ksoftirqd context
  D) generic kernel infrastructure with identical semantics on all archs

If you were to make something like a sleepable softirq, you'd loose A
(per definition), B (sleepable implies migratable to cpus_allowed) and
possibly D (unless you want to touch all architectures).

Now from your 'requirements':

> I have one case that needs to sleep (but only when interrupting user code)

> TIF works for user space, but it's a bit ugly because it requires adding
> more data to the task_struct because CPUs can change.

Which I read as:

 1) needs to run in the task context of the task that got 'interrupted'
 2) needs to stay on the cpu it got interrupted on.

So C is out of the window too, at which point there's nothing resembling
softirqs left.

To boot, x86_64 runs softirqs from the hardirq stack:

/* Call softirq on interrupt stack. Interrupts are off. */
ENTRY(call_softirq)
        CFI_STARTPROC
        push %rbp
        CFI_ADJUST_CFA_OFFSET   8
        CFI_REL_OFFSET rbp,0
        mov  %rsp,%rbp
        CFI_DEF_CFA_REGISTER rbp
        incl PER_CPU_VAR(irq_count)
        cmove PER_CPU_VAR(irq_stack_ptr),%rsp
        push  %rbp                      # backlink for old unwinder
        call __do_softirq
        leaveq
        CFI_DEF_CFA_REGISTER    rsp
        CFI_ADJUST_CFA_OFFSET   -8
        decl PER_CPU_VAR(irq_count)
        ret 
        CFI_ENDPROC
END(call_softirq) 

Also, -rt has something that could be considered sleepable softirqs,
although we call them preemptible softirqs. It runs all softirqs from
cpu bound kthreads, which again doesn't match your requirements.

So no, I don't think your idea of sleepable softirqs is sound.


  reply	other threads:[~2010-06-25 10:39 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-24  3:04 [RFC 1/5] Make soft_irq NMI safe Huang Ying
2010-06-24  3:04 ` [RFC 2/5] NMI return notifier Huang Ying
2010-06-24  3:04 ` [RFC 3/5] x86, trigger NMI return notifier soft_irq earlier Huang Ying
2010-06-24  6:03   ` Peter Zijlstra
2010-06-24  3:04 ` [RFC 4/5] x86, Use NMI return notifier in MCE Huang Ying
2010-06-24 10:00   ` Andi Kleen
2010-06-24  3:04 ` [RFC 5/5] Use NMI return notifier in perf pending Huang Ying
2010-06-24  6:00   ` Peter Zijlstra
2010-06-24  6:09 ` [RFC 1/5] Make soft_irq NMI safe Peter Zijlstra
2010-06-24  6:45   ` Huang Ying
2010-06-24  6:35 ` [RFC][PATCH] irq_work Peter Zijlstra
2010-06-24  6:43   ` Huang Ying
2010-06-24  6:47     ` Peter Zijlstra
2010-06-24  6:50       ` Huang Ying
2010-06-24  6:58         ` Peter Zijlstra
2010-06-24  7:04           ` Huang Ying
2010-06-24  7:19             ` Peter Zijlstra
2010-06-24  7:27               ` Huang Ying
2010-06-24  7:32                 ` Peter Zijlstra
2010-06-24 10:27                   ` Andi Kleen
2010-06-24 10:30                     ` Peter Zijlstra
2010-06-24 10:52                       ` Andi Kleen
2010-06-24 10:58                         ` Peter Zijlstra
2010-06-24 11:08                           ` Andi Kleen
2010-06-24 11:10                             ` Peter Zijlstra
2010-06-24 11:20                               ` Andi Kleen
2010-06-24 11:33                                 ` Peter Zijlstra
2010-06-24 11:55                                   ` Andi Kleen
2010-06-24 11:57                                     ` Peter Zijlstra
2010-06-24 12:02                                       ` Andi Kleen
2010-06-24 12:18                                         ` Peter Zijlstra
2010-06-24 12:38                                           ` Andi Kleen
2010-06-25 10:38                                             ` Peter Zijlstra [this message]
2010-06-24 11:42                                 ` Peter Zijlstra
2010-06-24 11:58                                   ` Andi Kleen
2010-06-24 12:02                                     ` Peter Zijlstra
2010-06-24 11:23                               ` Ingo Molnar
2010-06-24 11:34                                 ` Peter Zijlstra
2010-06-24 12:35                                   ` Ingo Molnar
2010-06-24 13:02                                     ` Andi Kleen
2010-06-24 13:20                                       ` Borislav Petkov
2010-06-24 13:33                                         ` Andi Kleen
2010-06-24 13:42                                           ` Ingo Molnar
2010-06-24 13:46                                           ` Ingo Molnar
2010-06-24 14:01                                             ` Andi Kleen
2010-06-24 15:41                                               ` Borislav Petkov
2010-06-24 16:09                                                 ` Andi Kleen
2010-06-25  2:12   ` Huang Ying
2010-06-25  7:48     ` Peter Zijlstra
2010-06-25  9:17       ` Huang Ying
2010-06-25  9:23         ` Frederic Weisbecker
2010-06-25  9:30           ` Huang Ying
2010-06-25  9:44             ` Frederic Weisbecker
2010-06-25  9:30         ` Peter Zijlstra
2010-06-25 11:58           ` huang ying
2010-06-25  9:08     ` Andi Kleen
2010-06-25 18:30   ` [RFC][PATCH] irq_work -v2 Peter Zijlstra
2010-06-25 19:30     ` Andi Kleen
2010-06-25 19:39       ` Peter Zijlstra
2010-06-25 19:49         ` Peter Zijlstra
2010-06-25 22:29         ` Andi Kleen
2010-06-26  8:36           ` Peter Zijlstra
2010-06-26 10:08             ` Andi Kleen
2010-06-26 10:32               ` Peter Zijlstra
2010-06-25 19:47       ` Peter Zijlstra
2010-06-26  1:26     ` huang ying

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=1277462331.32034.221.camel@twins \
    --to=peterz@infradead.org \
    --cc=andi@firstfloor.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=ying.huang@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.