At 13.56 14/06/02 -0700, David Schwartz wrote:
>On Thu, 13 Jun 2002 18:26:54 +0200, Roberto Fichera wrote:
> >At 04.58 13/06/02 -0700, David Schwartz wrote:
>
> >This is a scheduler problem! All threads waiting for I/O are blocked by
> >the scheduler, and this doesn't have any impact for the context switches
> >it increase only the waitqueue, using the Ingo's O(1) scheduler, a big piece
> >of code, it should make a big difference for example.
>
> You are incorrect. If you have ten threads each waiting for an
> I/O and all
>ten I/Os are ready, then ten context switches are needed. If you have one
>thread waiting for ten I/Os, and then I/Os come ready, one context switch is
>needed.
You are right with this specific case, but always depending what kind of I/O
you must be done. Not all the case could be reduce to your logic, only a
specific case. It's a only "local" optimization.
>[snip]
>
> >I don't think "more threads == more work done"! With the thread's approch
> >it's
> >possible to split a big sequential program in a variety of concurrent
> >logical
> >programs with a big win for code revisions and new implementation.
>
> I'm not advising eliminating the threads approach. I'm only
> advising not
>using threads as your abstraction for clients or work to be done. Use threads
>as the execution vehicles that pick up work when there's work to be done.
>(Think thread pools, think separating I/O from computation.)
Yes! This is what I want!
>[snip]
> >You are right! But depend by the application! If you have todo I/O like
> >signal acquisition,
> >sensors acquisitions and so on, you must have a one thread for each type of
> >data acquisition,
>
> Even if that's true, and it's often not, how many different types
> of data
>acquisition can you have? Ten? Twenty? That's a far cry from 300.
Currently are 190! Always active are ~110! So thinking by separating I/O from
the computation we double the threads.
Roberto Fichera.
-
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/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:33 EST