Re: PATCH: 8139too kernel thread
Linus Torvalds wrote: > But yes, on 2.4.x the cost of threads is fairly low. The biggest cost by > far is probably the locking needed for the scheduler etc, and there the > best rule of thumb is probably to see whether the driver really ends up > being noticeably simpler. My main motivations for moving media selection from a timer into a kernel thread are: * the timer oftens takes a lng time to run (some drivers have extra junk in the timer funcs that really should be in a kthread anyway), and * do_ioctl, which calls the mdio_xxx functions, holds rtnl_lock, which is a semaphore. the kernel thread can easily acquire this semaphore too, a timer can't. I agree that it needs to be examined on a case-by-case basis. Better hardware, where MDIO access is just a few bus reads/writes, probably doesn't need a kernel thread. Finally, for most net drivers, media selection occurs once every 60 seconds or so, not a big impact even on 2.2.x... > The event stuff that we are discussing for pcmcia may make all of this > moot, maybe media selection is the perfect example of how to do the very > same thing. I'll forward Jeff the emails on that. I think I'm already on the CC list. I'm confused here though How does tq_context apply here? Your suggested direction of tq_context seems ok, but I don't see how it applies to situations where polling needs to occur, like where yenta polls when request_irq fails, or when net drivers poll media selection here. Regards, Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: 8139too kernel thread
> > 8K of memory, two tlb flushes, cache misses on the scheduler. The price is > ^^^ > > actually extremely high. > > > Does it really need non-lazy TLB? Good point, so its a mere 8K of memory and the scheduler cache misses > I'm not saying that it's a good idea, but... It seems a very bad idea for the general case. It might be justified for a few drivers but then they should not use their own thread but (to merge two mail discussions together) use the generic api dwmw2 is doing to solve the pcmcia problem. Now we can sleep and we are back to a single 8K stack for all of it - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: 8139too kernel thread
On Thu, 16 Nov 2000, Alexander Viro wrote: > > On Thu, 16 Nov 2000, Alan Cox wrote: > > > > The only disadvantage to this scheme is the added cost of a kernel > > > thread over a kernel timer. I think this is an ok cost, because this > > > is a low-impact thread that sleeps a lot.. > > > > 8K of memory, two tlb flushes, cache misses on the scheduler. The price is > ^^^ > > actually extremely high. > > > Does it really need non-lazy TLB? If Alan wants to back-port it into 2.2.x, the lazy tlb won't work. But yes, on 2.4.x the cost of threads is fairly low. The biggest cost by far is probably the locking needed for the scheduler etc, and there the best rule of thumb is probably to see whether the driver really ends up being noticeably simpler. The event stuff that we are discussing for pcmcia may make all of this moot, maybe media selection is the perfect example of how to do the very same thing. I'll forward Jeff the emails on that. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: 8139too kernel thread
On Thu, 16 Nov 2000, Alan Cox wrote: > > The only disadvantage to this scheme is the added cost of a kernel > > thread over a kernel timer. I think this is an ok cost, because this > > is a low-impact thread that sleeps a lot.. > > 8K of memory, two tlb flushes, cache misses on the scheduler. The price is ^^^ > actually extremely high. Does it really need non-lazy TLB? I'm not saying that it's a good idea, but... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: 8139too kernel thread
> The only disadvantage to this scheme is the added cost of a kernel > thread over a kernel timer. I think this is an ok cost, because this > is a low-impact thread that sleeps a lot.. 8K of memory, two tlb flushes, cache misses on the scheduler. The price is actually extremely high. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: 8139too kernel thread
The only disadvantage to this scheme is the added cost of a kernel thread over a kernel timer. I think this is an ok cost, because this is a low-impact thread that sleeps a lot.. 8K of memory, two tlb flushes, cache misses on the scheduler. The price is actually extremely high. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: 8139too kernel thread
On Thu, 16 Nov 2000, Alan Cox wrote: The only disadvantage to this scheme is the added cost of a kernel thread over a kernel timer. I think this is an ok cost, because this is a low-impact thread that sleeps a lot.. 8K of memory, two tlb flushes, cache misses on the scheduler. The price is ^^^ actually extremely high. confused Does it really need non-lazy TLB? I'm not saying that it's a good idea, but... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: 8139too kernel thread
On Thu, 16 Nov 2000, Alexander Viro wrote: On Thu, 16 Nov 2000, Alan Cox wrote: The only disadvantage to this scheme is the added cost of a kernel thread over a kernel timer. I think this is an ok cost, because this is a low-impact thread that sleeps a lot.. 8K of memory, two tlb flushes, cache misses on the scheduler. The price is ^^^ actually extremely high. confused Does it really need non-lazy TLB? If Alan wants to back-port it into 2.2.x, the lazy tlb won't work. But yes, on 2.4.x the cost of threads is fairly low. The biggest cost by far is probably the locking needed for the scheduler etc, and there the best rule of thumb is probably to see whether the driver really ends up being noticeably simpler. The event stuff that we are discussing for pcmcia may make all of this moot, maybe media selection is the perfect example of how to do the very same thing. I'll forward Jeff the emails on that. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: 8139too kernel thread
8K of memory, two tlb flushes, cache misses on the scheduler. The price is ^^^ actually extremely high. confused Does it really need non-lazy TLB? Good point, so its a mere 8K of memory and the scheduler cache misses I'm not saying that it's a good idea, but... It seems a very bad idea for the general case. It might be justified for a few drivers but then they should not use their own thread but (to merge two mail discussions together) use the generic api dwmw2 is doing to solve the pcmcia problem. Now we can sleep and we are back to a single 8K stack for all of it - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: 8139too kernel thread
Linus Torvalds wrote: But yes, on 2.4.x the cost of threads is fairly low. The biggest cost by far is probably the locking needed for the scheduler etc, and there the best rule of thumb is probably to see whether the driver really ends up being noticeably simpler. My main motivations for moving media selection from a timer into a kernel thread are: * the timer oftens takes a lng time to run (some drivers have extra junk in the timer funcs that really should be in a kthread anyway), and * do_ioctl, which calls the mdio_xxx functions, holds rtnl_lock, which is a semaphore. the kernel thread can easily acquire this semaphore too, a timer can't. I agree that it needs to be examined on a case-by-case basis. Better hardware, where MDIO access is just a few bus reads/writes, probably doesn't need a kernel thread. Finally, for most net drivers, media selection occurs once every 60 seconds or so, not a big impact even on 2.2.x... The event stuff that we are discussing for pcmcia may make all of this moot, maybe media selection is the perfect example of how to do the very same thing. I'll forward Jeff the emails on that. I think I'm already on the CC list. I'm confused here though How does tq_context apply here? Your suggested direction of tq_context seems ok, but I don't see how it applies to situations where polling needs to occur, like where yenta polls when request_irq fails, or when net drivers poll media selection here. Regards, Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: 8139too kernel thread
Jeff Garzik wrote:
>
> (note Linus, not for applying...)
>
> Here is a patch, against 2.4.0-test11-pre2, that I wanted to forward
> to the lists for comment.
>
> Many of the ethernet drivers have timer routines, which are
> called every three-five seconds or so. These timer routines
> typically do stuff related to media selection or checking, and call
> mdio_{read,write} to interact with the phy.
>
I think it's useful. More generally, I'd like to have
"process context timers" - the ability to call a function
from process context at a set time. Then a single kernel
thread could handle all things like this. Pretty simple to do.
BTW: can the OOM killer possibly kill a kernel thread?
If it does, yenta_socket_thread() will nuke the machine.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: 8139too kernel thread
Jeff Garzik wrote:
(note Linus, not for applying...)
Here is a patch, against 2.4.0-test11-pre2, that I wanted to forward
to the lists for comment.
Many of the ethernet drivers have timer routines, which are
called every three-five seconds or so. These timer routines
typically do stuff related to media selection or checking, and call
mdio_{read,write} to interact with the phy.
I think it's useful. More generally, I'd like to have
"process context timers" - the ability to call a function
from process context at a set time. Then a single kernel
thread could handle all things like this. Pretty simple to do.
BTW: can the OOM killer possibly kill a kernel thread?
If it does, yenta_socket_thread() will nuke the machine.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
