Hi Juri,
Here is the pull request for the changes that create a workload generator tool
Regards,
The following changes since commit 17be4548c4260b80be623e0e1317e98a770dea7a:
copyright added (2014-04-11 09:28:27 +0200)
are available in the git repository at:
git://git.linaro.org/power/rt-app.git master
for you to fetch changes up to 8cbaad65d00e3c64c4f941139bc11f4d07822474:
add a web browsing use case (2014-08-01 15:43:47 +0200)
---------------------------------------------------------------- Chris Muller (1): Update thread name
Juri Lelli (1): remove dependecy from sched_setattr (and sched_getattr is useless here)
Kevin Hilman (1): KJH: test JSON merge tool
Sanjay Singh Rawat (1): add delay param in thread parameters
Vincent Guittot (46): Minor clean up fix deadline print format consolidate trace and debug point update .gitignore update the .json test file remove a stray int add loop feature rt-app: make load frequency independent. Add new resources update example file with new capabilities add sleep and run type of resources update taskset.json example fix inconsistency in delay unit fix cpu affinity string info make possible to remove the sleep step modify stat to reflect new behavior update example file with more capabilities priority: Add priority to SCHED_OTHER fix: force all threads to wake up when exit calibration: parse for CPU or forces ns per loop value update example file with new capabilities resource: new sync resource add a examples directory Older kernels do not support the commands sched_[g|s]etattr. timing array size remove trailing space deadline: set deadline field to deadline parameter reorder the start sequence of threads fix use case without resources update header file and README move merge examples files in examples directory cleanup of doc directory update taskset.json Remove AQUOSA scheduler add phase feature various minor clean up fix for exit sequence ensure that the exec will not underflow update the todo list several cleanup remove conditional compilation of json command line is no more supported with new feature renaming for better understanding add a very simple example add a simple example add a web browsing use case
.gitignore | 8 + README.in | 93 +----- TODO | 12 +- configure.ac | 30 +- doc/examples/browser.json | 225 ++++++++++++++ doc/examples/example1.json | 23 ++ doc/examples/example2.json | 34 +++ doc/examples/merge/global.json | 12 + doc/examples/merge/resources.json | 11 + doc/examples/merge/thread0.json | 15 + doc/examples/merge/thread1.json | 14 + doc/examples/merge/thread2.json | 13 + doc/examples/merge/thread3.json | 13 + doc/examples/mp3.json | 76 +++++ doc/merge.py | 42 +++ doc/taskset.json | 132 +++++---- doc/taskset.yml | 53 ---- src/Makefile.am | 2 - src/rt-app.c | 609 ++++++++++++++++++++++++-------------- src/rt-app.h | 5 +- src/rt-app_args.c | 333 +-------------------- src/rt-app_args.h | 4 +- src/rt-app_parse_config.c | 469 +++++++++++++++++++++-------- src/rt-app_parse_config.h | 2 + src/rt-app_types.h | 103 ++++--- src/rt-app_utils.c | 130 +++++--- src/rt-app_utils.h | 38 ++- 27 files changed, 1491 insertions(+), 1010 deletions(-) create mode 100644 doc/examples/browser.json create mode 100644 doc/examples/example1.json create mode 100644 doc/examples/example2.json create mode 100644 doc/examples/merge/global.json create mode 100644 doc/examples/merge/resources.json create mode 100644 doc/examples/merge/thread0.json create mode 100644 doc/examples/merge/thread1.json create mode 100644 doc/examples/merge/thread2.json create mode 100644 doc/examples/merge/thread3.json create mode 100644 doc/examples/mp3.json create mode 100755 doc/merge.py delete mode 100644 doc/taskset.yml
Hi Vincent,
I'm actually adding Chris to Cc: as he is also part of the original discussion about rt-app.
On 05/08/14 22:45, Vincent Guittot wrote:
Hi Juri,
Here is the pull request for the changes that create a workload generator tool
Regards,
The following changes since commit 17be4548c4260b80be623e0e1317e98a770dea7a:
copyright added (2014-04-11 09:28:27 +0200)
are available in the git repository at:
git://git.linaro.org/power/rt-app.git master
for you to fetch changes up to 8cbaad65d00e3c64c4f941139bc11f4d07822474:
add a web browsing use case (2014-08-01 15:43:47 +0200)
Thanks for sharing changes in your repository, but IMHO it is somewhat difficult to review them in this form, as behavioural changes are intermixed with small fixes. Also, it would be good if we can integrate changes keeping git history clean. Ideally we could introduce functional changes followed by (or together with) examples showing what feature the change introduces. I know that this is time consuming, so I'm actually asking if you think you have some time to work on rearranging things.
Having a proper history could also ease review. I'd say we could try two different methods. I created a GitHub organization that now hosts the rt-app repo: https://github.com/scheduler-tools/rt-app. I also created a branch for the original version of the tool so that we can integrate changes on master.
Method 1) We use GitHub pull request feature to discuss changes and finally integrate them.
Method 2) You post the patchset (based on master) on linaro-dev mailing list, discussion happens on the mailing list (everybody can participate), after discussion I apply patches resulting from discussion on master.
I'd personally prefer method 2 as it is simpler and can probably get contributions from a wider audience. What other thinks?
We also said that the name of the tool could be changed, any opinions on this? Something like workload-gen or wload-gen ?
Thanks a lot.
Best Regards,
- Juri
Chris Muller (1): Update thread name
Juri Lelli (1): remove dependecy from sched_setattr (and sched_getattr is useless here)
Kevin Hilman (1): KJH: test JSON merge tool
Sanjay Singh Rawat (1): add delay param in thread parameters
Vincent Guittot (46): Minor clean up fix deadline print format consolidate trace and debug point update .gitignore update the .json test file remove a stray int add loop feature rt-app: make load frequency independent. Add new resources update example file with new capabilities add sleep and run type of resources update taskset.json example fix inconsistency in delay unit fix cpu affinity string info make possible to remove the sleep step modify stat to reflect new behavior update example file with more capabilities priority: Add priority to SCHED_OTHER fix: force all threads to wake up when exit calibration: parse for CPU or forces ns per loop value update example file with new capabilities resource: new sync resource add a examples directory Older kernels do not support the commands sched_[g|s]etattr. timing array size remove trailing space deadline: set deadline field to deadline parameter reorder the start sequence of threads fix use case without resources update header file and README move merge examples files in examples directory cleanup of doc directory update taskset.json Remove AQUOSA scheduler add phase feature various minor clean up fix for exit sequence ensure that the exec will not underflow update the todo list several cleanup remove conditional compilation of json command line is no more supported with new feature renaming for better understanding add a very simple example add a simple example add a web browsing use case
.gitignore | 8 + README.in | 93 +----- TODO | 12 +- configure.ac | 30 +- doc/examples/browser.json | 225 ++++++++++++++ doc/examples/example1.json | 23 ++ doc/examples/example2.json | 34 +++ doc/examples/merge/global.json | 12 + doc/examples/merge/resources.json | 11 + doc/examples/merge/thread0.json | 15 + doc/examples/merge/thread1.json | 14 + doc/examples/merge/thread2.json | 13 + doc/examples/merge/thread3.json | 13 + doc/examples/mp3.json | 76 +++++ doc/merge.py | 42 +++ doc/taskset.json | 132 +++++---- doc/taskset.yml | 53 ---- src/Makefile.am | 2 - src/rt-app.c | 609 ++++++++++++++++++++++++-------------- src/rt-app.h | 5 +- src/rt-app_args.c | 333 +-------------------- src/rt-app_args.h | 4 +- src/rt-app_parse_config.c | 469 +++++++++++++++++++++-------- src/rt-app_parse_config.h | 2 + src/rt-app_types.h | 103 ++++--- src/rt-app_utils.c | 130 +++++--- src/rt-app_utils.h | 38 ++- 27 files changed, 1491 insertions(+), 1010 deletions(-) create mode 100644 doc/examples/browser.json create mode 100644 doc/examples/example1.json create mode 100644 doc/examples/example2.json create mode 100644 doc/examples/merge/global.json create mode 100644 doc/examples/merge/resources.json create mode 100644 doc/examples/merge/thread0.json create mode 100644 doc/examples/merge/thread1.json create mode 100644 doc/examples/merge/thread2.json create mode 100644 doc/examples/merge/thread3.json create mode 100644 doc/examples/mp3.json create mode 100755 doc/merge.py delete mode 100644 doc/taskset.yml
Hi Juri,
On Wed, Aug 6, 2014 at 3:38 PM, Juri Lelli juri.lelli@arm.com wrote:
Hi Vincent,
I'm actually adding Chris to Cc: as he is also part of the original discussion about rt-app.
On 05/08/14 22:45, Vincent Guittot wrote:
Hi Juri,
Here is the pull request for the changes that create a workload generator tool
Regards,
The following changes since commit 17be4548c4260b80be623e0e1317e98a770dea7a:
copyright added (2014-04-11 09:28:27 +0200)
are available in the git repository at:
git://git.linaro.org/power/rt-app.git master
for you to fetch changes up to 8cbaad65d00e3c64c4f941139bc11f4d07822474:
add a web browsing use case (2014-08-01 15:43:47 +0200)
Thanks for sharing changes in your repository, but IMHO it is somewhat difficult to review them in this form, as behavioural changes are intermixed with small fixes. Also, it would be good if we can integrate changes keeping git history clean. Ideally we could introduce functional changes followed by (or together with) examples showing what feature the change introduces. I know that this is time consuming, so I'm actually asking if you think you have some time to work on rearranging things.
Vincent is on vacations until the end of the month. After that, I expect he'll be busy with Linaro Connect preparations.
Yes, the timing of all this sucks given that we want to announce the tools this week to give 2 weeks of lead time before Kernel Summit.
Having a proper history could also ease review. I'd say we could try two different methods. I created a GitHub organization that now hosts the rt-app repo: https://github.com/scheduler-tools/rt-app. I also created a branch for the original version of the tool so that we can integrate changes on master.
Method 1) We use GitHub pull request feature to discuss changes and finally integrate them.
Method 2) You post the patchset (based on master) on linaro-dev mailing list, discussion happens on the mailing list (everybody can participate), after discussion I apply patches resulting from discussion on master.
I'd personally prefer method 2 as it is simpler and can probably get contributions from a wider audience. What other thinks?
I prefer Method 2 myself but it is going to be hard to get anything refactored until late September.
We also said that the name of the tool could be changed, any opinions on this? Something like workload-gen or wload-gen ?
IMHO, the name change is just a nice to have and not critical to the success of this project.
Regards, Amit
Hi Amit,
On 06/08/14 12:35, Amit Kucheria wrote:
Hi Juri,
On Wed, Aug 6, 2014 at 3:38 PM, Juri Lelli juri.lelli@arm.com wrote:
Hi Vincent,
I'm actually adding Chris to Cc: as he is also part of the original discussion about rt-app.
On 05/08/14 22:45, Vincent Guittot wrote:
Hi Juri,
Here is the pull request for the changes that create a workload generator tool
Regards,
The following changes since commit 17be4548c4260b80be623e0e1317e98a770dea7a:
copyright added (2014-04-11 09:28:27 +0200)
are available in the git repository at:
git://git.linaro.org/power/rt-app.git master
for you to fetch changes up to 8cbaad65d00e3c64c4f941139bc11f4d07822474:
add a web browsing use case (2014-08-01 15:43:47 +0200)
Thanks for sharing changes in your repository, but IMHO it is somewhat difficult to review them in this form, as behavioural changes are intermixed with small fixes. Also, it would be good if we can integrate changes keeping git history clean. Ideally we could introduce functional changes followed by (or together with) examples showing what feature the change introduces. I know that this is time consuming, so I'm actually asking if you think you have some time to work on rearranging things.
Vincent is on vacations until the end of the month. After that, I expect he'll be busy with Linaro Connect preparations.
Yes, the timing of all this sucks given that we want to announce the tools this week to give 2 weeks of lead time before Kernel Summit.
Having a proper history could also ease review. I'd say we could try two different methods. I created a GitHub organization that now hosts the rt-app repo: https://github.com/scheduler-tools/rt-app. I also created a branch for the original version of the tool so that we can integrate changes on master.
Method 1) We use GitHub pull request feature to discuss changes and finally integrate them.
Method 2) You post the patchset (based on master) on linaro-dev mailing list, discussion happens on the mailing list (everybody can participate), after discussion I apply patches resulting from discussion on master.
I'd personally prefer method 2 as it is simpler and can probably get contributions from a wider audience. What other thinks?
I prefer Method 2 myself but it is going to be hard to get anything refactored until late September.
So, I'd say we wait for the actual review process to happen when feasible anyway.
Thanks,
- Juri
We also said that the name of the tool could be changed, any opinions on this? Something like workload-gen or wload-gen ?
IMHO, the name change is just a nice to have and not critical to the success of this project.
Regards, Amit
On Thu, Aug 7, 2014 at 8:27 PM, Juri Lelli juri.lelli@arm.com wrote:
Hi Amit,
On 06/08/14 12:35, Amit Kucheria wrote:
Hi Juri,
On Wed, Aug 6, 2014 at 3:38 PM, Juri Lelli juri.lelli@arm.com wrote:
Hi Vincent,
I'm actually adding Chris to Cc: as he is also part of the original discussion about rt-app.
On 05/08/14 22:45, Vincent Guittot wrote:
Hi Juri,
Here is the pull request for the changes that create a workload generator tool
Regards,
The following changes since commit 17be4548c4260b80be623e0e1317e98a770dea7a:
copyright added (2014-04-11 09:28:27 +0200)
are available in the git repository at:
git://git.linaro.org/power/rt-app.git master
for you to fetch changes up to 8cbaad65d00e3c64c4f941139bc11f4d07822474:
add a web browsing use case (2014-08-01 15:43:47 +0200)
Thanks for sharing changes in your repository, but IMHO it is somewhat difficult to review them in this form, as behavioural changes are intermixed with small fixes. Also, it would be good if we can integrate changes keeping git history clean. Ideally we could introduce functional changes followed by (or together with) examples showing what feature the change introduces. I know that this is time consuming, so I'm actually asking if you think you have some time to work on rearranging things.
Vincent is on vacations until the end of the month. After that, I expect he'll be busy with Linaro Connect preparations.
Yes, the timing of all this sucks given that we want to announce the tools this week to give 2 weeks of lead time before Kernel Summit.
Having a proper history could also ease review. I'd say we could try two different methods. I created a GitHub organization that now hosts the rt-app repo: https://github.com/scheduler-tools/rt-app. I also created a branch for the original version of the tool so that we can integrate changes on master.
Method 1) We use GitHub pull request feature to discuss changes and finally integrate them.
Method 2) You post the patchset (based on master) on linaro-dev mailing list, discussion happens on the mailing list (everybody can participate), after discussion I apply patches resulting from discussion on master.
I'd personally prefer method 2 as it is simpler and can probably get contributions from a wider audience. What other thinks?
I prefer Method 2 myself but it is going to be hard to get anything refactored until late September.
So, I'd say we wait for the actual review process to happen when feasible anyway.
I agree. Admittedly the kernel summit deadlines and vacation schedules among other things have forced us to take some shortcuts.
We'll feed these patches back in small chunks over time. In the meanwhile, for the sake of the tools announcement, we'll just refer to the tree on g.l.o
We also said that the name of the tool could be changed, any opinions on this? Something like workload-gen or wload-gen ?
IMHO, the name change is just a nice to have and not critical to the success of this project.
Workload Generator is the obvious choice of name but not very Google-friendly. Can someone think of a suitable qualifier before it? It'd stick with rt-app until then.
Regards, Amit
Hi Amit,
On 08/08/14 06:27, Amit Kucheria wrote:
On Thu, Aug 7, 2014 at 8:27 PM, Juri Lelli juri.lelli@arm.com wrote:
Hi Amit,
On 06/08/14 12:35, Amit Kucheria wrote:
Hi Juri,
On Wed, Aug 6, 2014 at 3:38 PM, Juri Lelli juri.lelli@arm.com wrote:
Hi Vincent,
I'm actually adding Chris to Cc: as he is also part of the original discussion about rt-app.
On 05/08/14 22:45, Vincent Guittot wrote:
Hi Juri,
Here is the pull request for the changes that create a workload generator tool
Regards,
The following changes since commit 17be4548c4260b80be623e0e1317e98a770dea7a:
copyright added (2014-04-11 09:28:27 +0200)
are available in the git repository at:
git://git.linaro.org/power/rt-app.git master
for you to fetch changes up to 8cbaad65d00e3c64c4f941139bc11f4d07822474:
add a web browsing use case (2014-08-01 15:43:47 +0200)
Thanks for sharing changes in your repository, but IMHO it is somewhat difficult to review them in this form, as behavioural changes are intermixed with small fixes. Also, it would be good if we can integrate changes keeping git history clean. Ideally we could introduce functional changes followed by (or together with) examples showing what feature the change introduces. I know that this is time consuming, so I'm actually asking if you think you have some time to work on rearranging things.
Vincent is on vacations until the end of the month. After that, I expect he'll be busy with Linaro Connect preparations.
Yes, the timing of all this sucks given that we want to announce the tools this week to give 2 weeks of lead time before Kernel Summit.
Having a proper history could also ease review. I'd say we could try two different methods. I created a GitHub organization that now hosts the rt-app repo: https://github.com/scheduler-tools/rt-app. I also created a branch for the original version of the tool so that we can integrate changes on master.
Method 1) We use GitHub pull request feature to discuss changes and finally integrate them.
Method 2) You post the patchset (based on master) on linaro-dev mailing list, discussion happens on the mailing list (everybody can participate), after discussion I apply patches resulting from discussion on master.
I'd personally prefer method 2 as it is simpler and can probably get contributions from a wider audience. What other thinks?
I prefer Method 2 myself but it is going to be hard to get anything refactored until late September.
So, I'd say we wait for the actual review process to happen when feasible anyway.
I agree. Admittedly the kernel summit deadlines and vacation schedules among other things have forced us to take some shortcuts.
We'll feed these patches back in small chunks over time. In the meanwhile, for the sake of the tools announcement, we'll just refer to the tree on g.l.o
IMHO, it is perfectly fine to say in the announce that development is happening on g.l.o, patches will be reviewed on linaro-dev and code will then be merged on the official new repo on GitHub (https://github.com/scheduler-tools/rt-app).
This way the work Linaro is doing is advertised, but people don't get confused with all this different repos.
Does this look reasonable to you?
Thanks,
- Juri
We also said that the name of the tool could be changed, any opinions on this? Something like workload-gen or wload-gen ?
IMHO, the name change is just a nice to have and not critical to the success of this project.
Workload Generator is the obvious choice of name but not very Google-friendly. Can someone think of a suitable qualifier before it? It'd stick with rt-app until then.
Regards, Amit
On 08/08/2014 07:27 AM, Amit Kucheria wrote:
[ ... ]
We also said that the name of the tool could be changed, any opinions on this? Something like workload-gen or wload-gen ?
IMHO, the name change is just a nice to have and not critical to the success of this project.
Workload Generator is the obvious choice of name but not very Google-friendly. Can someone think of a suitable qualifier before it? It'd stick with rt-app until then.
1. Poetic
Sisyphean workload generator ?
As a punishment for his trickery, King Sisyphus was made to endlessly roll a huge boulder up a steep hill. The maddening nature of the punishment was reserved for King Sisyphus due to his hubristic belief that his cleverness surpassed that of Zeus himself. Zeus accordingly displayed his own cleverness by enchanting the boulder into rolling away from King Sisyphus before he reached the top which ended up consigning Sisyphus to an eternity of useless efforts and unending frustration. Thus it came to pass that pointless or interminable activities are sometimes described as Sisyphean.
2. Optimistic
Flexible workload generator ?
3. Straightforward
Programmable workload generator ?
On 08/08/14 10:35, Daniel Lezcano wrote:
- Poetic
Sisyphean workload generator ?
As a punishment for his trickery, King Sisyphus was made to endlessly roll a huge boulder up a steep hill. The maddening nature of the punishment was reserved for King Sisyphus due to his hubristic belief that his cleverness surpassed that of Zeus himself. Zeus accordingly displayed his own cleverness by enchanting the boulder into rolling away from King Sisyphus before he reached the top which ended up consigning Sisyphus to an eternity of useless efforts and unending frustration. Thus it came to pass that pointless or interminable activities are sometimes described as Sisyphean.
Along the same lines, I'll do you one better:
Paranoid workload generator
Paranoia is a thought process believed to be heavily influenced by anxiety or fear, often to the point of irrationality and delusion. Paranoid thinking typically includes persecutory beliefs, or beliefs of conspiracy concerning a perceived threat towards oneself (e.g. "Everyone is out to get me").
From a more grounded but sort of poetic perspective, I would offer:
mimic/mimicry: as a play on mimicking real workload patterns (mimicking: the act or art of copying or imitating closely). So the tool would be called 'mimicry' which sounds kind of cool (at least to me).
silhouette: as a play on well, the silhouette of workload patterns kind of thing.
Or in the straightforward (boring/functional) category:
workgen
Robin
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
On 8 Aug 2014, at 14:20, "Robin Randhawa" robin.randhawa@arm.com wrote:
So Daniel and I spoke offline and improved each other's understanding of Greek mythology a bit more. :)
No paranoid Gods or delusional Rolling Stones please. (Or any ensuing misunderstandings!).
The rest of the bits are still up for discussion if anyone's interested:
From a more grounded but sort of poetic perspective, I would offer:
mimic/mimicry: as a play on mimicking real workload patterns (mimicking: the act or art of copying or imitating closely). So the tool would be called 'mimicry' which sounds kind of cool (at least to me).
silhouette: as a play on well, the silhouette of workload patterns kind of thing.
Or in the straightforward (boring/functional) category:
workgen
Thanks, Robin
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
On 8 Aug 2014, at 14:20, "Robin Randhawa" robin.randhawa@arm.com wrote:
So Daniel and I spoke offline and improved each other's understanding of Greek mythology a bit more. :)
No paranoid Gods or delusional Rolling Stones (and anything that did or could cause misunderstandings!).
From a more grounded but sort of poetic perspective, I would offer:
mimic/mimicry: as a play on mimicking real workload patterns (mimicking: the act or art of copying or imitating closely). So the tool would be called 'mimicry' which sounds kind of cool (at least to me).
silhouette: as a play on well, the silhouette of workload patterns kind of thing.
Or in the straightforward (boring/functional) category:
workgen
Plus Daniel's other suggestions:
2. Optimistic
Flexible workload generator ?
3. Straightforward
Programmable workload generator ?
Anyone ?
Thanks, Robin
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Hi Juri,
As Amit explains, the coming weeks will be quite busy but i will reorder the patchset as soon as i find available time.
Regards, Vincent
On 7 August 2014 16:57, Juri Lelli juri.lelli@arm.com wrote:
Hi Amit,
On 06/08/14 12:35, Amit Kucheria wrote:
Hi Juri,
On Wed, Aug 6, 2014 at 3:38 PM, Juri Lelli juri.lelli@arm.com wrote:
Hi Vincent,
I'm actually adding Chris to Cc: as he is also part of the original discussion about rt-app.
On 05/08/14 22:45, Vincent Guittot wrote:
Hi Juri,
Here is the pull request for the changes that create a workload generator tool
Regards,
The following changes since commit 17be4548c4260b80be623e0e1317e98a770dea7a:
copyright added (2014-04-11 09:28:27 +0200)
are available in the git repository at:
git://git.linaro.org/power/rt-app.git master
for you to fetch changes up to 8cbaad65d00e3c64c4f941139bc11f4d07822474:
add a web browsing use case (2014-08-01 15:43:47 +0200)
Thanks for sharing changes in your repository, but IMHO it is somewhat difficult to review them in this form, as behavioural changes are intermixed with small fixes. Also, it would be good if we can integrate changes keeping git history clean. Ideally we could introduce functional changes followed by (or together with) examples showing what feature the change introduces. I know that this is time consuming, so I'm actually asking if you think you have some time to work on rearranging things.
Vincent is on vacations until the end of the month. After that, I expect he'll be busy with Linaro Connect preparations.
Yes, the timing of all this sucks given that we want to announce the tools this week to give 2 weeks of lead time before Kernel Summit.
Having a proper history could also ease review. I'd say we could try two different methods. I created a GitHub organization that now hosts the rt-app repo: https://github.com/scheduler-tools/rt-app. I also created a branch for the original version of the tool so that we can integrate changes on master.
Method 1) We use GitHub pull request feature to discuss changes and finally integrate them.
Method 2) You post the patchset (based on master) on linaro-dev mailing list, discussion happens on the mailing list (everybody can participate), after discussion I apply patches resulting from discussion on master.
I'd personally prefer method 2 as it is simpler and can probably get contributions from a wider audience. What other thinks?
I prefer Method 2 myself but it is going to be hard to get anything refactored until late September.
So, I'd say we wait for the actual review process to happen when feasible anyway.
Thanks,
- Juri
We also said that the name of the tool could be changed, any opinions on this? Something like workload-gen or wload-gen ?
IMHO, the name change is just a nice to have and not critical to the success of this project.
Regards, Amit
Hi Vincent,
On 26/08/14 12:11, Vincent Guittot wrote:
Hi Juri,
As Amit explains, the coming weeks will be quite busy but i will reorder the patchset as soon as i find available time.
No problem.
Thanks,
- Juri
Regards, Vincent
On 7 August 2014 16:57, Juri Lelli juri.lelli@arm.com wrote:
Hi Amit,
On 06/08/14 12:35, Amit Kucheria wrote:
Hi Juri,
On Wed, Aug 6, 2014 at 3:38 PM, Juri Lelli juri.lelli@arm.com wrote:
Hi Vincent,
I'm actually adding Chris to Cc: as he is also part of the original discussion about rt-app.
On 05/08/14 22:45, Vincent Guittot wrote:
Hi Juri,
Here is the pull request for the changes that create a workload generator tool
Regards,
The following changes since commit 17be4548c4260b80be623e0e1317e98a770dea7a:
copyright added (2014-04-11 09:28:27 +0200)
are available in the git repository at:
git://git.linaro.org/power/rt-app.git master
for you to fetch changes up to 8cbaad65d00e3c64c4f941139bc11f4d07822474:
add a web browsing use case (2014-08-01 15:43:47 +0200)
Thanks for sharing changes in your repository, but IMHO it is somewhat difficult to review them in this form, as behavioural changes are intermixed with small fixes. Also, it would be good if we can integrate changes keeping git history clean. Ideally we could introduce functional changes followed by (or together with) examples showing what feature the change introduces. I know that this is time consuming, so I'm actually asking if you think you have some time to work on rearranging things.
Vincent is on vacations until the end of the month. After that, I expect he'll be busy with Linaro Connect preparations.
Yes, the timing of all this sucks given that we want to announce the tools this week to give 2 weeks of lead time before Kernel Summit.
Having a proper history could also ease review. I'd say we could try two different methods. I created a GitHub organization that now hosts the rt-app repo: https://github.com/scheduler-tools/rt-app. I also created a branch for the original version of the tool so that we can integrate changes on master.
Method 1) We use GitHub pull request feature to discuss changes and finally integrate them.
Method 2) You post the patchset (based on master) on linaro-dev mailing list, discussion happens on the mailing list (everybody can participate), after discussion I apply patches resulting from discussion on master.
I'd personally prefer method 2 as it is simpler and can probably get contributions from a wider audience. What other thinks?
I prefer Method 2 myself but it is going to be hard to get anything refactored until late September.
So, I'd say we wait for the actual review process to happen when feasible anyway.
Thanks,
- Juri
We also said that the name of the tool could be changed, any opinions on this? Something like workload-gen or wload-gen ?
IMHO, the name change is just a nice to have and not critical to the success of this project.
Regards, Amit
+++ Vincent Guittot [2014-08-05 23:45 +0200]:
Hi Juri,
Here is the pull request for the changes that create a workload generator tool
Regards,
The following changes since commit 17be4548c4260b80be623e0e1317e98a770dea7a:
copyright added (2014-04-11 09:28:27 +0200)
are available in the git repository at:
git://git.linaro.org/power/rt-app.git master
rt-app is now available in Debian unstable: https://packages.qa.debian.org/r/rt-app.html
If the authors can poke me where there are significant new releases to upload that would be helpful (now that no-one actually _does_ releases anymore and you just have to know when a 'good' git commit point happens :-)
That should propogate to ubuntu too, but doesn't seem to have done so yet, and they just froze imports to utopic, so $someone should poke $someone if we want this.
Wookey
-
Amit Kucheria -
Daniel Lezcano -
Juri Lelli -
Robin Randhawa -
Robin Randhawa
-
Vincent Guittot -
Wookey