On Tuesday, January 31, 2012 05:11:19 AM gene heskett did opine: > On Tuesday, January 31, 2012 01:49:57 AM gene heskett did opine: > > On Tuesday, January 31, 2012 01:33:48 AM Kent A. Reed did opine: > > > On 1/30/2012 11:35 PM, gene heskett wrote: > > > > So at the moment, I'm back to being bumfuzzled again. No clue > > > > what I changed that would have screwed up the older emc-2.6.0-pre > > > > after its been reinstalled. > > > > > > Me neither. The only time I have fired up the pre-releases has to > > > check for occurrences of the "brand that shall not be named." I > > > checked the Configuration Selector, made sure Axis came up, ran the > > > sim/axis_mm demo, and then shut down. > > > > I found the answer! Another msg is approaching that I cross-posted > > back to lkml. Fixed it right up and I believe this answer will be > > useful to all who are running on a multicore system. > > The crosspost didn't work apparently, came from the wrong email account > I suppose. > > Anyway, the answer is 'taskset' see the manpage. > > So I wrote a 3 line script to use taskset to launch emc AND pin it to > the 2nd cpu core. Runs sweet & likely 50% faster than I ever ran > before once I get done fine tuning the base_thread time in the .ini > file. 32 u-secs is only using 26% of that core, so there is room to > play yet. > > The script: > -------------- > #!/bin/bash > taskset 0x00000002 /usr/bin/emc -l & > exit 0 > -------------- > > Note the manpage explains that the 2nd argument above very obtusely. > cpu0 would be 0x00000001, cpu2 then would be 0x00000004, cpu3 is then > 0x00000008. etc etc. Bit wise control starting from the ls bit IOW. > And if the cores are available, you can set it to use 2 or more.
Yeah, I know, it is considered 'poor form' to answer ones own postings, but I seem to have some additional data to share. Give me 20 lashes with a wet noodle or something for the "poor form". First, I am now able to set the BASE_THREAD at 25000, where it now uses 30% of cpu1 when idle, and 50% of cpu1 when running the logo. Keyboard response is quite snappy yet, I'd go so far as to say as quick as the keydown & keyups can get through the cable its seen & responded to. Then I thought I would check latency-test when launched by taskset, pinned to cpu1. At 25 u-secs it shows less than 2% usage of cpu1, and the latencies were very stable, never going over 3 u-secs. The display update, probably running on cpu0, raises cpu0 usage about 20%. I think these are very encouraging numbers and those of us running on atom boards (and probably on other multicore boards too) should be making use of taskset to pin our stuff to the otherwise unused cpu when we have specifically isolated one of the cores in our grub.cfg files. I think, but have no way of proving it, that the latency-test result improvements we were seeing previously, were no more than the simple removal of the migration times from the measurements since it had no other cpu to migrate to. There may be a downside, but I haven't found it yet if there is one. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> Talking about music is like dancing about architecture. -- Laurie Anderson ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
