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
> > 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,
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..
> >
> >
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
> 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
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
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
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,
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,
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
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
>
(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
(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
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
14 matches
Mail list logo