hey On Mon, Jan 21, 2013 at 6:48 PM, Sonny Karlsson <[email protected]> wrte:
> On Mon, Jan 21, 2013 at 03:00:50PM -0600, Eduardo Silva wrote: > > On Mon, Jan 21, 2013 at 12:56 PM, Sonny Karlsson <[email protected]> > wrote: > > > > > On Mon, Jan 21, 2013 at 08:06:10PM +0200, Lauri Kasanen wrote: > > > > On Mon, 21 Jan 2013 18:16:14 +0100 > > > > Sonny Karlsson <[email protected]> wrote: > > > > > > > > + # is set to 0 monkey will launch one processor per thread. > > > > > > > > This line says it the wrong way around. Launching processors ;) > > > > > > > That would have been a pretty awesome feature. ;] > > > Attached new version with a more realistic comment. > > > Thanks for noticia more realistic > > > > > > > - Lauri > > > > > > -- > > > Sonny Karlsson > > > > > > _______________________________________________ > > > Monkey mailing list > > > [email protected] > > > http://lists.monkey-project.com/listinfo/monkey > > > > > > > > Hey!, thanks for the patch, but we have a few things to consider: it does > > not matter in terms of scalability if we launch the same number of > workers > > per processor if the task is not assigned to it. I mean, this is totally > > correct and make sense to enable SMP on-demand. For years i have been > > opposite to implement this in the core due to the project targets which > is > > Embedded Linux. But things have changed a little in terms of processors > on > > different devices so we can do something different without affect the > core. > > So i propose the following: > > > > Create a SMP plugin which auto-magically spawn N workers as N online CPU > > cores exists. And each worker is assigned to a specific CPU, you can > check > > more of this in sched_setaffinity(2). This plugin is build by default but > > must be enabled manually in conf/plugins.load. > > > > Then we can implement a smp.conf file to define more strict policies > about > > how the workers are distributed among the CPU cores available. > > > > comments ? > > I've already tried setting CPU affinity where each thread is assigned > one core, but Monkey's data is isolated enough that the kernel does > better scheduling decision without forced affinity. Performance is > decreased whenever another process is running on the same computer using > N:N threads:processors with affinity compared to without, and nearly > unchanged when monkey is alone. > > I've only tested this on one system and only a few configurations so my > observations may not be entirely accurate, but they make sense to me. > Also some plugin with shares state between threads may alter the effect of > affinity, but that is just speculation on my part. > > It make sense, i will do some tests with high load and changing affinity to see if it improve something... > My motivation for this patch is resource conservation. Monkey doesn't > benefit from more threads than processors available and too many may > actually decrease performance due to context switches. Launching as many > threads as there are processors seems like a reasonable default. Also, > less threads use less system resources. > > It make sense too, but.. the problem is that Linux Kernel assign threads to the same CPU by default. I dont consider bad to include this change and sounds reasonable, i will apply the patch and continue some research about SMP stuff. So workers = 0 will spawn depending of online CPUs. Just one more question for Davidlohr, what happen in Linux SMP when some CPU core change its state to offline ?, how that affects the running tasks assigned to it ?, is this informed to the affected tasks in user space ? thanks, > > > > -- > > Eduardo Silva > > http://edsiper.linuxchile.cl > > http://www.monkey-project.com > > -- > Sonny Karlsson > -- Eduardo Silva http://edsiper.linuxchile.cl http://www.monkey-project.com
_______________________________________________ Monkey mailing list [email protected] http://lists.monkey-project.com/listinfo/monkey
