lkml.org 
[lkml]   [2002]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Developing multi-threading applications
At 12.30 15/06/02 +0200, Ingo Oeser wrote:

>On Sat, Jun 15, 2002 at 11:01:44AM +0200, Roberto Fichera wrote:
> > > 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.
>
>So basically you are just traversing your data depedency graph
>wrongly. Do a level order traversion if it is a dependency forest
>or an breadth first traversion if not.

Ok! I've semplified too much ;-)!

>If this node require IO -> schedule the IO and return back to the upper
>level noticing it, that you like to be woken, if the IO is
>finished.
>
>If this node require Computation -> do it, if this CPU is the one with
>lowest load, else schedule it for the CPU with lowest load.

How can I do it ? Shouldn't be a kernel problem ? I could collect
a various patch around that implement a CPU process bind/affinity and
CPU load balance but how can I determine which CPU have the lowest
load in a given time ?

>Continue with next node.
>
>(load is meant "number of compuations with same metric scheduled
>on this thread")
>
>Use only one thread per CPU. Try to make the IO-Waiting as unique
>as possible (poll would be perfect).

This could be implemented by the process affinity to bind the
process to a CPU. But I continue to not hunderstand why
I must have only one thread per CPU. There is some URL
where can I see some kernel/sched/vm/I-O/other-think graph about
this point ?


>So this is all doable, once you analyze your data dependency
>graph properly and make the simulation data driven (which it
>usally is).
>
>Regards
>
>Ingo Oeser
>--
>Science is what we can tell a computer. Art is everything else. --- D.E.Knuth

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/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.090 / U:2.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site