Hello
I'm an end user of your work , and appreciate all you are doing.
My goal is to have a 2 sec Meego boot time for Automotive .I think if we can merge your work into a "best of both" bootchart, then such an approach would greatly benefit people working on fast boot type project. Also I'd imagine one bootchart project is enough if it has the correct contributors. As for enabling CONFIG_TASKSTATS=y people can rebuild there kernel as needed, for the analysis phase and use the default kernel when deployed. Thanks Ger. -----Original Message----- From: Michael Meeks [mailto:[email protected]] Sent: Tuesday, March 30, 2010 11:07 AM To: Kok, Auke-jan H Cc: Maloney, Gerard; [email protected] Subject: Bootchart2 / bootchart duplication ... Hi Auke, On Mon, 2010-03-29 at 09:59 -0700, Auke Kok wrote: > > If we can get CONFIG_TASKSTATS=y turned on for MeeGo, I'm happy to > > package & maintain the bootchart2 package - which is prettier of course. > > We're currently planning to ship the new bootchart I originally wrote > (sorry Michael :)) for Moblin. Well, reading the code it seems you took a somewhat different - albeit interesting approach. No doubt we should fallback to the schedstat data as/when taskstats is not present [1]. Having said that - it seems that schedstat has a granularity of 1ms - which seems somewhat too chunky to see lots of bitty activity on a fast CPU - bouncing to/fro from gconfd eg. Taskstats is in theory ns (though it increases in a suspiciously chunky fashion ;-). I see lots of apparently idle processes using your bootchart during boot, but the visualisation is quite nice. I still think it would be better to have taskstats turned on in your kernel. > With all the moving around going on here I haven't had the time to > publish the code on a git repo yet, but we'll do that as soon as a > meego git repo is running. My views on this sort of Intel internal re-writing are well known. There is a good way to do this: work with the existing guys on the various bootchart projects out there, and try to draw them together. That is the approach I took with bootchart2. It is also far, far less wasteful of the scarce resources that we (collectively) have today to work on tooling. You are of course more than welcome to have bootchart2 commit access if you want to get changes in there; I would love to see that - I'm not precious about ownership. There is a good way to do software development in community; and IMNSHO it doesn't look like this. We don't need yet-another bootchart project[2] there are currently a handful (now +1). Luckily I am not a volunteer community member, who has a single much-loved project they want to contribute to MeeGo, and whom would just wander off in disgust at this point. Conversely - at least you tried with your README - though strangely no people are named in it except you: software doesn't write itself ;-). In the meantime as/when I get cycles, I will try to merge your work (properly credited etc.), and see if there are any rendering innovations bootchart2 can re-use. Then I'll submit it for inclusion in MeeGo & see where we get. Regards, Michael. [1] - TASKSTATS is a horrible interface anyway - and rather too slow to poll since it screws up accounting for threads. Any kernel geniuses want to explain how it can be used for a thread-group ? Of course, more ideally there would be a /proc/taskstats file with all the ns timing data required for all tasks (including their threads) that can be accessed with a single open/read/close: and that is consistent and correct for that open syscall time. [2] - and of course, this new bootchart doesn't address the nasty problems of initrds, and the other general linux distro problems that are out there: to be fair bootchart2 is only half-way towards my current pipe-dream solution here: using ptrace to grab data out of the logger post boot :-) Ah - and a real nasty - the parent/child (ppid) relationship is pointless in a boot-chart, we want "who forked whom" - which we can get from a probe (it seems); plenty to do there. -- [email protected] <><, Pseudo Engineer, itinerant idiot
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
