[RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers - Kernel

This is a discussion on [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers - Kernel ; On Thu, 2 Oct 2008, Daniel Walker wrote: > On Thu, 2008-10-02 at 11:02 -0400, Steven Rostedt wrote: > > On Wed, 1 Oct 2008, Daniel Walker wrote: > > > > > > > > Converting an interrupt to ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 47

Thread: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

  1. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

    On Thu, 2 Oct 2008, Daniel Walker wrote:
    > On Thu, 2008-10-02 at 11:02 -0400, Steven Rostedt wrote:
    > > On Wed, 1 Oct 2008, Daniel Walker wrote:
    > > > >
    > > > > Converting an interrupt to threaded makes only sense when the handler
    > > > > code takes advantage of it by integrating tasklet/softirq
    > > > > functionality and simplifying the locking.
    > > >
    > > > I'm not clear on your direction here.. I don't have a problem with a
    > > > mass driver audit, which I think is what your suggesting with this patch
    > > > set .. However, a mass audit like that would push a fully real time
    > > > system out for quite some time..

    > >
    > > This has nothing to do with real time, although it helps.

    >
    > Clearly threading irq handlers does have something to do with real time,
    > unless this patch isn't actually threading anything ..


    Clearly you have neither clue about real time nor about operating
    systems in general.

    Solaris, some BSDs and MacOSX use interrupt threads. Where exactly is
    the relation to realtime?

    The concept of interrupt threads is nothing which is in any way
    related to real time. It is a well known and pretty old concept in
    operating system design.

    The fact that real time operating systems benefit from interrupt
    threads is a totally different topic.

    tglx

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

    On Thu, 2008-10-02 at 20:42 +0200, Thomas Gleixner wrote:

    > Clearly you have neither clue about real time nor about operating
    > systems in general.


    Here we go again Thomas.. You think you can have a conversation without
    the insults for once?

    > Solaris, some BSDs and MacOSX use interrupt threads. Where exactly is
    > the relation to realtime?


    The very fact that you mention it in your release notes .. You mention
    the type of system in "preempt-rt" and the advantage of your system..

    > The concept of interrupt threads is nothing which is in any way
    > related to real time. It is a well known and pretty old concept in
    > operating system design.
    >
    > The fact that real time operating systems benefit from interrupt
    > threads is a totally different topic.
    >


    The fact that a direct relationship exists means that any threaded
    interrupt system needs to take into account the inevitable connection to
    real time since it will be used in that system as a core component.. If
    you can't effectively achieve real time with your system , than that's a
    problem that needs to be addressed.

    Daniel

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers


    On Thu, 2 Oct 2008, Daniel Walker wrote:

    > On Thu, 2008-10-02 at 20:42 +0200, Thomas Gleixner wrote:
    >
    > > Clearly you have neither clue about real time nor about operating
    > > systems in general.

    >
    > Here we go again Thomas.. You think you can have a conversation without
    > the insults for once?
    >
    > > Solaris, some BSDs and MacOSX use interrupt threads. Where exactly is
    > > the relation to realtime?

    >
    > The very fact that you mention it in your release notes .. You mention
    > the type of system in "preempt-rt" and the advantage of your system..
    >
    > > The concept of interrupt threads is nothing which is in any way
    > > related to real time. It is a well known and pretty old concept in
    > > operating system design.
    > >
    > > The fact that real time operating systems benefit from interrupt
    > > threads is a totally different topic.
    > >

    >
    > The fact that a direct relationship exists means that any threaded
    > interrupt system needs to take into account the inevitable connection to
    > real time since it will be used in that system as a core component.. If
    > you can't effectively achieve real time with your system , than that's a
    > problem that needs to be addressed.


    Daniel, what kind of logic is this? I was already accused of being on
    crack today (but was just too much coffee). Perhaps you might be the one
    that's on crack.

    I build a pipe. There exists a relationship between a pipe and crap
    running through it from my toilet. Does this mean that every time I need a
    pipe, that I need to take into account the inevitable connection to crap
    to run through it?

    God, I can see the problems with my gas lines.

    -- Steve

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers


    * Daniel Walker wrote:

    > > > Clearly threading irq handlers does have something to do with real
    > > > time, unless this patch isn't actually threading anything ..


    Well, that's clearly wrong: threaded IRQ handlers are not tied to
    real-time in any way. Yes, they can be used for RT too but as far as the
    upstream kernel is involved that's at most an afterthought.

    and the "unless this patch isn't actually threading anything" bit does
    not parse at all. The patches execute hard-IRQ handlers from special
    kernel threads.

    > > Clearly you have neither clue about real time nor about operating
    > > systems in general.

    >
    > Here we go again Thomas.. You think you can have a conversation
    > without the insults for once?


    what Thomas said was a strong but fair reaction to your obviously
    incorrect statement. What reaction did you expect?

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

    On Thu, 2008-10-02 at 21:28 +0200, Ingo Molnar wrote:
    > * Daniel Walker wrote:
    >
    > > > > Clearly threading irq handlers does have something to do with real
    > > > > time, unless this patch isn't actually threading anything ..

    >
    > Well, that's clearly wrong: threaded IRQ handlers are not tied to
    > real-time in any way. Yes, they can be used for RT too but as far as the
    > upstream kernel is involved that's at most an afterthought.


    You contradict yourself .. I said "Clearly threading irq handlers does
    have something to do with real time" then you say "they can be used for
    RT too" .. So my comments are clearly correct , they have "something" to
    do with real time. There exists a relationship of some kind or type.

    You should go back and read my initial questions, they are reasonable ..

    > > > Clearly you have neither clue about real time nor about operating
    > > > systems in general.

    > >
    > > Here we go again Thomas.. You think you can have a conversation
    > > without the insults for once?

    >
    > what Thomas said was a strong but fair reaction to your obviously
    > incorrect statement. What reaction did you expect?


    We need less insults on this list not more.. Maybe I could understand
    his reaction had I insulted him, but I didn't.. "Fair reaction" doesn't
    fit in this case ..

    Daniel

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers


    On Thu, 2 Oct 2008, Daniel Walker wrote:

    > On Thu, 2008-10-02 at 21:28 +0200, Ingo Molnar wrote:
    > > * Daniel Walker wrote:
    > >
    > > > > > Clearly threading irq handlers does have something to do with real
    > > > > > time, unless this patch isn't actually threading anything ..

    > >
    > > Well, that's clearly wrong: threaded IRQ handlers are not tied to
    > > real-time in any way. Yes, they can be used for RT too but as far as the
    > > upstream kernel is involved that's at most an afterthought.

    >
    > You contradict yourself .. I said "Clearly threading irq handlers does


    No he did not.

    > have something to do with real time" then you say "they can be used for
    > RT too" .. So my comments are clearly correct , they have "something" to
    > do with real time. There exists a relationship of some kind or type.



    What Ingo is telling you is:

    - RT needs threaded interrupts.

    - Threaded interrupts do not need RT

    My dog is an Italian Greyhound.

    Italian Greyhound is a dog, but
    a dog is not an Italian Greyhound.

    -- Steve

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

    On Thu, 2008-10-02 at 16:14 -0400, Steven Rostedt wrote:
    > On Thu, 2 Oct 2008, Daniel Walker wrote:
    >
    > > On Thu, 2008-10-02 at 21:28 +0200, Ingo Molnar wrote:
    > > > * Daniel Walker wrote:
    > > >
    > > > > > > Clearly threading irq handlers does have something to do with real
    > > > > > > time, unless this patch isn't actually threading anything ..
    > > >
    > > > Well, that's clearly wrong: threaded IRQ handlers are not tied to
    > > > real-time in any way. Yes, they can be used for RT too but as far as the
    > > > upstream kernel is involved that's at most an afterthought.

    > >
    > > You contradict yourself .. I said "Clearly threading irq handlers does

    >
    > No he did not.


    Yes, he did.

    > > have something to do with real time" then you say "they can be used for
    > > RT too" .. So my comments are clearly correct , they have "something" to
    > > do with real time. There exists a relationship of some kind or type.

    >
    >
    > What Ingo is telling you is:
    >
    > - RT needs threaded interrupts.
    >
    > - Threaded interrupts do not need RT
    >
    > My dog is an Italian Greyhound.
    >
    > Italian Greyhound is a dog, but
    > a dog is not an Italian Greyhound.


    My comments are basically bidirectional , so what your saying doesn't
    make any sense .. I said basically, that dogs and "Italian Greyhounds"
    have _some_ connection .. Why are we even debating this.

    Daniel

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers


    On Thu, 2 Oct 2008, Daniel Walker wrote:
    > >
    > > What Ingo is telling you is:
    > >
    > > - RT needs threaded interrupts.
    > >
    > > - Threaded interrupts do not need RT
    > >
    > > My dog is an Italian Greyhound.
    > >
    > > Italian Greyhound is a dog, but
    > > a dog is not an Italian Greyhound.

    >
    > My comments are basically bidirectional , so what your saying doesn't
    > make any sense .. I said basically, that dogs and "Italian Greyhounds"
    > have _some_ connection .. Why are we even debating this.



    Let's look at your original comments:

    > I'm not clear on your direction here.. I don't have a problem with a
    > mass driver audit, which I think is what your suggesting with this patch
    > set .. However, a mass audit like that would push a fully real time
    > system out for quite some time..


    Why are you bringing up real time in this thread?? The thread has
    absolutely nothing to do with real time. This thread is about a better
    way to handle interrupt handlers.

    >
    > I also don't see a clear connection between these changes and ultimately
    > removing spinlock level latency in the kernel. I realize you don't
    > address that in your comments, but this is part of the initiative to
    > remove spinlock level latency..


    Again, this thread has nothing to do with removing spinlock level latency.
    The reason Thomas did not address this is because it is OFF TOPIC!!!!

    >
    > So with this set of changes and in terms of real time, I'm wonder your
    > going with this ?


    You brought in this relationship with real time, just because real time
    uses threaded interrupts. This thread has nothing to do with real time.
    That is what Ingo, Thomas and myself are trying to ge through to you.

    The strong reaction from Thomas is that you just brought up something that
    is completely off topic.

    Basically, drop the real time topic from this thread. It's not related.
    Yes real time addresses threaded interrupts, but just because we are
    talking about threaded interrupts does not mean we are talking about real
    time.

    Actually my analogy with dogs and IG's is wrong. The pipe and crap analogy
    is better. Crap uses pipes to get out of the house. But if I'm talking
    about pipes, I don't want to hear about crap.

    We are debating this because YOU brought it up!

    -- Steve

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

    On Thu, Oct 02, 2008 at 04:46:09PM +0200, Andi Kleen wrote:
    > Thomas Gleixner writes:
    > >
    > > - move long running handlers out of the hard interrupt context

    >
    > I'm not sure I'm really looking forward to this brave new world
    > of very long running interrupt handlers. e.g. what do you
    > do for example when some handler blocks for a very long time?


    We have this issue today with some irqs (USB is known for issue here...)

    So I don't think this is a big issue, and in the end, a better idea as
    it might force us to confront some of the big abusers and fix them.

    thanks,

    greg k-h
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

    On Thu, 2008-10-02 at 17:05 -0400, Steven Rostedt wrote:

    > Why are you bringing up real time in this thread?? The thread has
    > absolutely nothing to do with real time. This thread is about a better
    > way to handle interrupt handlers.


    I'm concerned about the connection between the two, which is what I'm
    commenting on.

    > >
    > > I also don't see a clear connection between these changes and ultimately
    > > removing spinlock level latency in the kernel. I realize you don't
    > > address that in your comments, but this is part of the initiative to
    > > remove spinlock level latency..

    >
    > Again, this thread has nothing to do with removing spinlock level latency.
    > The reason Thomas did not address this is because it is OFF TOPIC!!!!


    If they are connected (which I think we established) , then it's not out
    of line for me to discuss the direction of these changes as related to
    other components of real time.

    > >
    > > So with this set of changes and in terms of real time, I'm wonder your
    > > going with this ?

    >
    > You brought in this relationship with real time, just because real time
    > uses threaded interrupts. This thread has nothing to do with real time.
    > That is what Ingo, Thomas and myself are trying to ge through to you.


    You know Steven, often times you start a conversation and you have no
    idea where it will end up.. You can't always control which direction it
    will go..

    > The strong reaction from Thomas is that you just brought up something that
    > is completely off topic.


    We already debated this fact Steven. real time and this type of
    threading are connected. It's not off topic to discuss connected
    components.

    If the intent here is to totally disconnect these threading patches from
    any type of real time in the future, then that's a good answer to my
    original question .. That these changes have no future what so ever in
    regards to real time.

    If they will be used in the future for real time then we should discuss
    it. I don't think that's off topic at all.

    > Basically, drop the real time topic from this thread. It's not related.
    > Yes real time addresses threaded interrupts, but just because we are
    > talking about threaded interrupts does not mean we are talking about real
    > time.


    I don't see why you are so concerned with this.. Real time is taboo now?

    Daniel

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [RFC patch 2/5] genirq: add a quick check handler

    On Thu, Oct 02, 2008 at 06:51:49AM -0400, Jon Masters wrote:
    > On Thu, 2008-10-02 at 01:09 -0400, Steven Rostedt wrote:
    > > On Wed, 1 Oct 2008, Jon Masters wrote:
    > > >
    > > > We probably need some documentation eventually so people realize what
    > > > this "quickcheck" handler is for and what it's not for - under no
    > > > circumstances should anything more than the bare minimum be done.
    > > > Otherwise it breaks the benefit of deferred threaded handling. It's hard
    > > > to enforce that - but this is *not* a return of top/bottom half handling
    > > > where you can do whatever crap you like in the quickcheck bit.
    > > >

    > >
    > > We could always implement something similar to what I was told Microsoft
    > > does (I was just told this, I don't know for fact). Time this function and
    > > if it takes longer than, say 50us, print a warning and kill the device
    > > ;-)

    >
    > You know, it's funny you suggested that because I thought about going
    > there. But there's probably some silly patent on that groundshattering
    > Microsoft solution to the halting problem.
    >
    > Anyway, I like to think we in the Linux community trust developers to do
    > the right thing more than Microsoft does


    "Trust, but verify"

    We should just print out something if it takes longer than Xus, that way
    we can fix the code, something that other operating systems can't do.

    thanks,

    greg k-h
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

    On Wed, Oct 01, 2008 at 08:40:14PM -0400, Jon Masters wrote:
    > On Wed, 2008-10-01 at 23:02 +0000, Thomas Gleixner wrote:
    >
    > > I hope to have a real converted driver (aside of the dummy module used
    > > for testing) ready real soon - as far as bugs/regressions stay out of
    > > my way for a while.

    >
    > Sven and I started poking at the various USB host drivers on the flight
    > back from Plumbers. I'll see if I can convert over a few here on the
    > systems that I have and send over some patches.


    There's only 3, how hard could it be?

    /me runs away quickly
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers



    On Thu, 2 Oct 2008, Daniel Walker wrote:

    > On Thu, 2008-10-02 at 17:05 -0400, Steven Rostedt wrote:
    >
    > > Why are you bringing up real time in this thread?? The thread has
    > > absolutely nothing to do with real time. This thread is about a better
    > > way to handle interrupt handlers.

    >
    > I'm concerned about the connection between the two, which is what I'm
    > commenting on.


    Well, please take that up separately. Do you see these patches going
    into the -rt tree? No, they are going in mainline. We will deal with
    them for -rt when the time comes.

    >
    > > >
    > > > I also don't see a clear connection between these changes and ultimately
    > > > removing spinlock level latency in the kernel. I realize you don't
    > > > address that in your comments, but this is part of the initiative to
    > > > remove spinlock level latency..

    > >
    > > Again, this thread has nothing to do with removing spinlock level latency.
    > > The reason Thomas did not address this is because it is OFF TOPIC!!!!

    >
    > If they are connected (which I think we established) , then it's not out
    > of line for me to discuss the direction of these changes as related to
    > other components of real time.


    You are bringing up concerns about mainline changes with something that
    is maintained outside the mainline tree. Changes to mainline have never
    been influenced by changes maintained outside of mainline.

    >
    > > >
    > > > So with this set of changes and in terms of real time, I'm wonder your
    > > > going with this ?

    > >
    > > You brought in this relationship with real time, just because real time
    > > uses threaded interrupts. This thread has nothing to do with real time.
    > > That is what Ingo, Thomas and myself are trying to ge through to you.

    >
    > You know Steven, often times you start a conversation and you have no
    > idea where it will end up.. You can't always control which direction it
    > will go..


    Yes Daniel, I know. But this is not a conversation. This is a email thread
    that is talking about changes to mainline. The mainline kernel developers
    really don't care about any issues that these changes will do to the
    real time project. The real time project is a niche, and is currently
    outside the mainline tree. Hence, lets stop bothering mainline
    developers with our issues.

    >
    > > The strong reaction from Thomas is that you just brought up something that
    > > is completely off topic.

    >
    > We already debated this fact Steven. real time and this type of
    > threading are connected. It's not off topic to discuss connected
    > components.


    No Daniel, it is off topic. The thread is not about real time issues.
    This thread is about mainline. If you have an issue that these changes
    will make to the current mainline tree, then please, by all means, bring
    them up. But do not bring up issues that only affect outside of mainline.

    >
    > If the intent here is to totally disconnect these threading patches from
    > any type of real time in the future, then that's a good answer to my
    > original question .. That these changes have no future what so ever in
    > regards to real time.


    No the intent here is to handle mainline issues. The real time issues you
    consistantly bring up are not important to most kernel developers. If
    you have real time issues with this change, bring that up on a real
    time forum. Not in this thread. The changes in this thread are dealing
    with mainline interrupt handlers. There have been several kernel device
    driver writers who asked us to get interrupt threads in mainline. This was
    not about real time, this was about helping out mainline kernel
    developers.

    >
    > If they will be used in the future for real time then we should discuss
    > it. I don't think that's off topic at all.
    >
    > > Basically, drop the real time topic from this thread. It's not related.
    > > Yes real time addresses threaded interrupts, but just because we are
    > > talking about threaded interrupts does not mean we are talking about real
    > > time.

    >
    > I don't see why you are so concerned with this.. Real time is taboo now?


    Not at all, Daniel, but this thread is not the appropriate place to
    discuss your real time concerns. You are asking about what this patch has
    to do with the future real time direction. Who on this thread cares?
    (besides you)

    The topic for mainline patch threads needs to stay focused on mainline.
    Not on out of tree branches. When the rest of real time is in mainline,
    then sure, you can discuss those concerns then. But until that happens,
    keep to the topic of the thread. Which for now is not real time.

    -- Steve

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

    On Thu, 2 Oct 2008 14:31:46 -0700
    Greg KH wrote:

    > On Thu, Oct 02, 2008 at 04:46:09PM +0200, Andi Kleen wrote:
    > > Thomas Gleixner writes:
    > > >
    > > > - move long running handlers out of the hard interrupt context

    > >
    > > I'm not sure I'm really looking forward to this brave new world
    > > of very long running interrupt handlers. e.g. what do you
    > > do for example when some handler blocks for a very long time?

    >
    > We have this issue today with some irqs (USB is known for issue
    > here...)
    >
    > So I don't think this is a big issue, and in the end, a better idea as
    > it might force us to confront some of the big abusers and fix them.
    >


    one of the things irq threads gives you is that 'top' will show you
    which ones are eating cpu ;-)


    --
    Arjan van de Ven Intel Open Source Technology Centre
    For development, discussion and tips for power savings,
    visit http://www.lesswatts.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

    On Thu, 2008-10-02 at 18:28 -0400, Steven Rostedt wrote:
    >
    > On Thu, 2 Oct 2008, Daniel Walker wrote:
    >
    > > On Thu, 2008-10-02 at 17:05 -0400, Steven Rostedt wrote:
    > >
    > > > Why are you bringing up real time in this thread?? The thread has
    > > > absolutely nothing to do with real time. This thread is about a better
    > > > way to handle interrupt handlers.

    > >
    > > I'm concerned about the connection between the two, which is what I'm
    > > commenting on.

    >
    > Well, please take that up separately. Do you see these patches going
    > into the -rt tree? No, they are going in mainline. We will deal with
    > them for -rt when the time comes.


    It's an RFC after all, it's not going into anything at this point..

    > >
    > > > >
    > > > > I also don't see a clear connection between these changes and ultimately
    > > > > removing spinlock level latency in the kernel. I realize you don't
    > > > > address that in your comments, but this is part of the initiative to
    > > > > remove spinlock level latency..
    > > >
    > > > Again, this thread has nothing to do with removing spinlock level latency.
    > > > The reason Thomas did not address this is because it is OFF TOPIC!!!!

    > >
    > > If they are connected (which I think we established) , then it's not out
    > > of line for me to discuss the direction of these changes as related to
    > > other components of real time.

    >
    > You are bringing up concerns about mainline changes with something that
    > is maintained outside the mainline tree. Changes to mainline have never
    > been influenced by changes maintained outside of mainline.


    Again it's an RFC .. It's not going into mainline..

    > >
    > > > >
    > > > > So with this set of changes and in terms of real time, I'm wonder your
    > > > > going with this ?
    > > >
    > > > You brought in this relationship with real time, just because real time
    > > > uses threaded interrupts. This thread has nothing to do with real time.
    > > > That is what Ingo, Thomas and myself are trying to ge through to you.

    > >
    > > You know Steven, often times you start a conversation and you have no
    > > idea where it will end up.. You can't always control which direction it
    > > will go..

    >
    > Yes Daniel, I know. But this is not a conversation. This is a email thread
    > that is talking about changes to mainline. The mainline kernel developers
    > really don't care about any issues that these changes will do to the
    > real time project. The real time project is a niche, and is currently
    > outside the mainline tree. Hence, lets stop bothering mainline
    > developers with our issues.


    Your speaking for a lot of developers.. It's an RFC, it's coming from
    real time developers, it's real time connected, and this is the real
    time development list ..

    Your preempt-rt patch isn't even what I'm commenting on.

    > >
    > > > The strong reaction from Thomas is that you just brought up something that
    > > > is completely off topic.

    > >
    > > We already debated this fact Steven. real time and this type of
    > > threading are connected. It's not off topic to discuss connected
    > > components.

    >
    > No Daniel, it is off topic. The thread is not about real time issues.
    > This thread is about mainline. If you have an issue that these changes
    > will make to the current mainline tree, then please, by all means, bring
    > them up. But do not bring up issues that only affect outside of mainline.


    The issues I've brought up are specifically design comments/concerns
    related to future directions.. I was not at all speaking to your real
    time changes..

    > >
    > > If the intent here is to totally disconnect these threading patches from
    > > any type of real time in the future, then that's a good answer to my
    > > original question .. That these changes have no future what so ever in
    > > regards to real time.

    >
    > No the intent here is to handle mainline issues. The real time issues you
    > consistantly bring up are not important to most kernel developers. If
    > you have real time issues with this change, bring that up on a real
    > time forum. Not in this thread. The changes in this thread are dealing
    > with mainline interrupt handlers. There have been several kernel device
    > driver writers who asked us to get interrupt threads in mainline. This was
    > not about real time, this was about helping out mainline kernel
    > developers.


    Real time forum ? That's what this list is .. If you want this thread to
    stop , you should stop responding to my comments .. Really Steven ..

    > >
    > > If they will be used in the future for real time then we should discuss
    > > it. I don't think that's off topic at all.
    > >
    > > > Basically, drop the real time topic from this thread. It's not related.
    > > > Yes real time addresses threaded interrupts, but just because we are
    > > > talking about threaded interrupts does not mean we are talking about real
    > > > time.

    > >
    > > I don't see why you are so concerned with this.. Real time is taboo now?

    >
    > Not at all, Daniel, but this thread is not the appropriate place to
    > discuss your real time concerns. You are asking about what this patch has
    > to do with the future real time direction. Who on this thread cares?
    > (besides you)


    People that don't care about real time related comments, they can stop
    reading the thread.. That's the nature of this list ..

    Daniel

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

    On Thu, 2 Oct 2008, Daniel Walker wrote:
    > On Thu, 2008-10-02 at 18:28 -0400, Steven Rostedt wrote:
    > > > > Why are you bringing up real time in this thread?? The thread has
    > > > > absolutely nothing to do with real time. This thread is about a better
    > > > > way to handle interrupt handlers.
    > > >
    > > > I'm concerned about the connection between the two, which is what I'm
    > > > commenting on.

    > >
    > > Well, please take that up separately. Do you see these patches going
    > > into the -rt tree? No, they are going in mainline. We will deal with
    > > them for -rt when the time comes.

    >
    > It's an RFC after all, it's not going into anything at this point..


    Because you are deciding what's going into mainline, right ?

    > > You are bringing up concerns about mainline changes with something that
    > > is maintained outside the mainline tree. Changes to mainline have never
    > > been influenced by changes maintained outside of mainline.

    >
    > Again it's an RFC .. It's not going into mainline..


    You made such a statement vs. hrtimers some time ago.

    > > Yes Daniel, I know. But this is not a conversation. This is a email thread
    > > that is talking about changes to mainline. The mainline kernel developers
    > > really don't care about any issues that these changes will do to the
    > > real time project. The real time project is a niche, and is currently
    > > outside the mainline tree. Hence, lets stop bothering mainline
    > > developers with our issues.

    >
    > Your speaking for a lot of developers.. It's an RFC, it's coming from
    > real time developers, it's real time connected, and this is the real
    > time development list ..


    This RFC patch is from a mainline developer/ maintainer who happens to
    be a real time developer as well.

    Welcome to my real time incoherent nonsense filter

    tglx
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

    On Thu, Oct 02, 2008 at 02:31:46PM -0700, Greg KH wrote:
    > On Thu, Oct 02, 2008 at 04:46:09PM +0200, Andi Kleen wrote:
    > > Thomas Gleixner writes:
    > > >
    > > > - move long running handlers out of the hard interrupt context

    > >
    > > I'm not sure I'm really looking forward to this brave new world
    > > of very long running interrupt handlers. e.g. what do you
    > > do for example when some handler blocks for a very long time?

    >
    > We have this issue today with some irqs (USB is known for issue here...)
    >
    > So I don't think this is a big issue, and in the end, a better idea as
    > it might force us to confront some of the big abusers and fix them.


    Not sure I follow? You're saying you want to first allow very long running
    IRQ handlers and then after the fact somehow fix them? Sounds like a weird
    proposal to be honest.

    The problem of course is that if you have such a very slow hardirq (let's
    say one that runs for tens of ms) that what happens when another
    interrupt comes in? How deep is your hardware queue? Or will you
    just lose events in that case?

    I suspect in the end you'll need another "fast interrupt" anyways
    if the hardware queue is not deep enough to buffer at the software
    side. Sounds a bit like the existing "interrupts" vs "softirq"
    doesn't it?

    So I'm just not sure what the "slow interrupt handler" will give
    you longer term. It just sounds like a redundant concept to me.

    The other issue is that if you allow sleeping locks in the interrupt
    handler what guarantee is that it won't block for even longer than
    tens of milliseconds? And lose even more events.

    -Andi

    --
    ak@linux.intel.com
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

    On Thu, Oct 02, 2008 at 03:33:05PM -0700, Arjan van de Ven wrote:
    > On Thu, 2 Oct 2008 14:31:46 -0700
    > Greg KH wrote:
    >
    > > On Thu, Oct 02, 2008 at 04:46:09PM +0200, Andi Kleen wrote:
    > > > Thomas Gleixner writes:
    > > > >
    > > > > - move long running handlers out of the hard interrupt context
    > > >
    > > > I'm not sure I'm really looking forward to this brave new world
    > > > of very long running interrupt handlers. e.g. what do you
    > > > do for example when some handler blocks for a very long time?

    > >
    > > We have this issue today with some irqs (USB is known for issue
    > > here...)
    > >
    > > So I don't think this is a big issue, and in the end, a better idea as
    > > it might force us to confront some of the big abusers and fix them.
    > >

    >
    > one of the things irq threads gives you is that 'top' will show you
    > which ones are eating cpu ;-)


    oprofile does that job fine already and is imho any time preferable
    for detailed analysis.

    -andi

    --
    ak@linux.intel.com
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

    On Fri, 3 Oct 2008 05:25:04 +0200
    Andi Kleen wrote:

    > >
    > > one of the things irq threads gives you is that 'top' will show you
    > > which ones are eating cpu ;-)

    >
    > oprofile does that job fine already and is imho any time preferable
    > for detailed analysis.


    while I don't disagree that oprofile will give you more detailed
    results, I think there's a HUGE difference between asking a bugreporter
    "can you paste a screen of 'top'" and "can you configure and run
    oprofile".
    CHances are good that the user already thought of top him/herself and
    just reports "interrupt X is eating CPU" rather than "something seems
    to be eating CPU".

    I'm not going argue that this alone is enough justification for
    irqthreads, but you can't deny it's an advantage.


    --
    Arjan van de Ven Intel Open Source Technology Centre
    For development, discussion and tips for power savings,
    visit http://www.lesswatts.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

    > while I don't disagree that oprofile will give you more detailed
    > results, I think there's a HUGE difference between asking a bugreporter
    > "can you paste a screen of 'top'" and "can you configure and run
    > oprofile".


    Perhaps the better fix would be to make oprofile easier to configure.
    I never quite understood for example why it doesn't get the symbol
    table simply from the kallsyms. Or simply unpacks gzip'ed vmlinux
    by itself.

    > CHances are good that the user already thought of top him/herself and
    > just reports "interrupt X is eating CPU" rather than "something seems
    > to be eating CPU".


    >
    > I'm not going argue that this alone is enough justification for
    > irqthreads, but you can't deny it's an advantage.


    Do we have that many cases of runaway irqs? The only common
    one I can think of is ACPI, but that is a separate thread already.

    Or for networking high performance goes into polling mode
    and most of the work is outside hardirq so it wouldn't be visible
    in the thread statistics either. But even there livelocks are not
    very common.

    Also that would assume that the proposed opt in irq threads are used
    for all interrupts.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast