Re: [Xenomai-core] [Adeos-main] AT91 patch duplicated code ...
2007/6/8, Gilles Chanteperdrix <[EMAIL PROTECTED]>: > BOUIN Alexandre wrote: > > > > > When we released our last version of adeos-ipipe-2.6.19-arm-AT91.patch, > we suggested to merge code for at91rm9200 and at91sam926x. > > > These 2 code are split but quite similar, so we think it could be a good > idea. Are you OK for removing duplicated code ? > > If I have to choose between duplicating some Linux code in I-pipe code > and have some duplication in the I-pipe patch, I choose duplication in > the I-pipe patch. If you duplicate Linux code, you will have to avoid > forgetting to update this duplicate code when Linux code evolves. > Well the first mail wasn't very clear. I am going to explain what we have in mind. In Linux code for AT91 timer there are two files: at91sam926x_time.c and at91rm9200_time.c because AT91RM9200 and AT91SAM926x have different system timer: AT91RM9200 use AT91_ST peripheral and AT91SAM926x use AT91_PIT peripheral. But with i-pipe we use TC (timer counter) in both case, and code is the same (the only difference are in the name of internal function). When CONFIG_IPIPE is defined, original Linux code is no more used and it is new i-pipe code which is used. I suggest to add a new file in i-pipe patch, let's call it "at91ipipe_time.c". In this file we will find the common ipipe code. This file will be compiled in place of at91sam926x_time.c and at91rm9200_time.c. For doing this we just have to change Makefile with something like this: # CPU-specific support obj-$(CONFIG_ARCH_AT91RM9200) += at91rm9200.o at91rm9200_devices.o obj-$(CONFIG_ARCH_AT91SAM9260) += at91sam9260.o at91sam9260_devices.o obj-$(CONFIG_ARCH_AT91SAM9261) += at91sam9261.o at91sam9261_devices.o ifeq ($(CONFIG_IPIPE),y) obj-$(CONFIG_ARCH_AT91RM9200) += at91ipipe_time.o obj-$(CONFIG_ARCH_AT91SAM9260) += at91ipipe_time.o obj-$(CONFIG_ARCH_AT91SAM9261) += at91ipipe_time.o at91sam9261_devices.o else obj-$(CONFIG_ARCH_AT91RM9200) += at91rm9200_time.o obj-$(CONFIG_ARCH_AT91SAM9260) += at91sam926x_time.o obj-$(CONFIG_ARCH_AT91SAM9261) += at91sam926x_time.o endif -- Gregory CLEMENT Adeneo 2, chemin du Ruisseau - BP21 69136 Ecully Cedex France Tel : +33-4 72 18 08 40 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] AT91 patch duplicated code ...
BOUIN Alexandre wrote: > > > When we released our last version of adeos-ipipe-2.6.19-arm-AT91.patch, we > > suggested to merge code for at91rm9200 and at91sam926x. > > These 2 code are split but quite similar, so we think it could be a good > > idea. Are you OK for removing duplicated code ? If I have to choose between duplicating some Linux code in I-pipe code and have some duplication in the I-pipe patch, I choose duplication in the I-pipe patch. If you duplicate Linux code, you will have to avoid forgetting to update this duplicate code when Linux code evolves. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] periodic mode in adeos-ipipe for arm at91 ...
BOUIN Alexandre wrote: > We (Adeneo) are working on a ARM AT91 RTAI. We encountered some > difficulties such tsc one : in periodic mode, we reload our timer > automatically in order to avoid reprogramming it. TC timer increments a 16 > byte register, which is not enough for a tsc (64 bytes). tsc need to be > emulated on ARM. > With oneshot mode, tsc is updating the 4 least significant > bytes and then increments other bytes each time counter go back to zero > value. > > With our periodic mode, timer reloads himself so we need to > change tsc emulation by incrementing tsc like this : tsc += period. > We made some evolutions on ipipe which will be applied to a hal > patch. I intend to rework I-pipe tsc emulation for arms with a free-running counter. In order to reduce the tsc read operations: - it should use the (uninterruptible) ldm instruction to load the 64 bits counter without masking interrupts; - the 64 bits counter should not be updated at each read, but only from time to time, the best place to do this is Linux timer interrupt. So, if you are ready to do these modifications, I will be glad to merge your patch. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai-help] measuring tasks execution time
Jan Kiszka wrote: > ... > - Note that migrating life-time stats between CPUs requires rebasing the > thread start time properly. Nonsense. CPU-local clocks are considered offset-free for Xenomai use. signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai-help] measuring tasks execution time
Daniel Simon wrote: > On Fri, 08 Jun 2007 13:20:11 +0200 > Jan Kiszka <[EMAIL PROTECTED]> wrote: > >> Daniel Simon wrote: >>> On Thu, 07 Jun 2007 19:44:47 +0200 >>> Jan Kiszka <[EMAIL PROTECTED]> wrote: >>> >>> Hello, opening a new thead forking from the one opened yesterday by Arnaud >>> Desvages >> I moved the thread to xenomai-core, hope you don't mind. > > OK, I guess it is the right place > [...] >>> Our goal is computing the accumulated cost of some selected real-time tasks >>> to get an image of the cpu load. >>> >>> What we need is a record of the accumulated execution time of the >>> rt_tasks (not the response time, hence the instants when the task is >>> preempted or suspended must not be counted). >>> This record must be accessible at any time, either from the calling >>> task or by another one. >>> >>> Our current patch only does that for tasks running in primary mode (and >>> moreover the measure seems not correctly updated for the calling >>> task record). >>> >>> Thus we would be very happy to get an improved instrumentation api. >>> I understand that xnstat_runtime_update() handles the measure we need? >> It was designed to collect precise runtime statistics to be displayed in >> /proc/xenomai/stat. We would just have to keep a total counter for each >> task as dumping /proc resets the statistics ATM. >> >>> Making it available, e.g. via a rt_task_inquire call, would be great! >> Well, the best (==most comfortable :o) ) way from my POV would be if you >> could try rebasing your work on your own first. Questions, even on minor >> details, are always welcome, review on patches will be provided. Should >> be no problem to get this into Xenomai 2.4. >> >> The rough to-do list would be: >> >> o add some persistent runtimer counter to xnthread::stat and maintain >>it >> o introduce an xnpod service (inline function) to obtain it (let that >>thing return [0..LONGLONG_MAX] when stats are available, -1 >>otherwise) >> o export the runtime via struct rt_task_info, maybe also the task start >>time >> >> Jan >> > I am afraid that it is far beyond my own programming capabilities, and I have > no > longer skilled enough students at hand... > Anyway there are some highly skilled (and overloaded) engineers around, i'll > try > to hire one of them! Any support is welcome, offers still stand! Damn, meanwhile I started thinking about this more than I wanted. So, whoever will implement it, a few more remarks/suggestions: - Considering the existing xnthread:stime and its usage (I didn't found a place), I would say just add another xnstat_runtime_t to xnthread::stat for life-time statistics and delete stime. - Note that migrating life-time stats between CPUs requires rebasing the thread start time properly. - And then I think we could also dump the life-time CPU usage based on that new data in /proc/xenomai/stat. Would be a nice test besides the native API extension... :-> Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] periodic mode in adeos-ipipe for arm at91 ...
On Fri, 2007-06-08 at 16:07 +0200, BOUIN Alexandre wrote: > We (Adeneo) are working on a ARM AT91 RTAI. We > encountered some difficulties such tsc one : in > periodic mode, we reload our timer automatically in > order to avoid reprogramming it. TC timer increments a > 16 byte register, which is not enough for a tsc (64 > bytes). tsc need to be emulated on ARM. > > With oneshot mode, tsc is updating the 4 least > significant bytes and then increments other bytes each > time counter go back to zero value. > > With our periodic mode, timer reloads himself so we > need to change tsc emulation by incrementing tsc like > this : tsc += period. > > We made some evolutions on ipipe which will be applied > to a hal patch. > > Are you interrested in a such patch for a periodic > mode on ARM ? > Support for periodic mode has been recently deprecated in the I-pipe patch, and will be discontinued in future releases. > ___ > Adeos-main mailing list > [EMAIL PROTECTED] > https://mail.gna.org/listinfo/adeos-main -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] periodic mode in adeos-ipipe for arm at91 ...
We (Adeneo) are working on a ARM AT91 RTAI. We encountered some difficulties such tsc one : in periodic mode, we reload our timer automatically in order to avoid reprogramming it. TC timer increments a 16 byte register, which is not enough for a tsc (64 bytes). tsc need to be emulated on ARM. With oneshot mode, tsc is updating the 4 least significant bytes and then increments other bytes each time counter go back to zero value. With our periodic mode, timer reloads himself so we need to change tsc emulation by incrementing tsc like this : tsc += period. We made some evolutions on ipipe which will be applied to a hal patch. Are you interrested in a such patch for a periodic mode on ARM ? ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai-help] measuring tasks execution time
On Fri, 08 Jun 2007 13:20:11 +0200 Jan Kiszka <[EMAIL PROTECTED]> wrote: > Daniel Simon wrote: > > On Thu, 07 Jun 2007 19:44:47 +0200 > > Jan Kiszka <[EMAIL PROTECTED]> wrote: > > > > Hello, opening a new thead forking from the one opened yesterday by Arnaud > > Desvages > > I moved the thread to xenomai-core, hope you don't mind. OK, I guess it is the right place > > [...] > > Our goal is computing the accumulated cost of some selected real-time tasks > > to get an image of the cpu load. > > > > What we need is a record of the accumulated execution time of the > > rt_tasks (not the response time, hence the instants when the task is > > preempted or suspended must not be counted). > > This record must be accessible at any time, either from the calling > > task or by another one. > > > > Our current patch only does that for tasks running in primary mode (and > > moreover the measure seems not correctly updated for the calling > > task record). > > > > Thus we would be very happy to get an improved instrumentation api. > > I understand that xnstat_runtime_update() handles the measure we need? > > It was designed to collect precise runtime statistics to be displayed in > /proc/xenomai/stat. We would just have to keep a total counter for each > task as dumping /proc resets the statistics ATM. > > > Making it available, e.g. via a rt_task_inquire call, would be great! > > Well, the best (==most comfortable :o) ) way from my POV would be if you > could try rebasing your work on your own first. Questions, even on minor > details, are always welcome, review on patches will be provided. Should > be no problem to get this into Xenomai 2.4. > > The rough to-do list would be: > > o add some persistent runtimer counter to xnthread::stat and maintain >it > o introduce an xnpod service (inline function) to obtain it (let that >thing return [0..LONGLONG_MAX] when stats are available, -1 >otherwise) > o export the runtime via struct rt_task_info, maybe also the task start >time > > Jan > I am afraid that it is far beyond my own programming capabilities, and I have no longer skilled enough students at hand... Anyway there are some highly skilled (and overloaded) engineers around, i'll try to hire one of them! Daniel -- Daniel SIMONProjet NeCS INRIA Rhone-Alpes Inovallee, 655 avenue de l'Europe, Montbonnot 38 334 Saint Ismier Cedex France [EMAIL PROTECTED] Phone:(33)476615328 Fax:(33)476615252 http://necs.inrialpes.fr/people/simon/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] AT91 patch duplicated code ...
BOUIN Alexandre wrote: > Gilles asked for some people to test > adeos-ipipe-2.6.20-arm-1.7-03.patch. As we said, our board are > always ready to receive new releases. > > Once 2.6.20 kernel unpacked, I've started patching it with > Xenomai, including last release of Adeos patch. I've kept last > releases of our libs cause nothing seems block us to use them with > a new kernel. Our Buildroot is using glibc and kernel has no debug > traces. If you did not do it recompile Xenomai kernel-space from trunk or branch v2.3.x svn. The new patch can not work with older kernel-space support. -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] AT91 patch duplicated code ...
> When we released our last version of adeos-ipipe-2.6.19-arm-AT91.patch, we > suggested to merge code for at91rm9200 and at91sam926x. > These 2 code are split but quite similar, so we think it could be a good > idea. Are you OK for removing duplicated code ? > > https://mail.gna.org/public/xenomai-core/2007-04/msg00040.html ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai-help] measuring tasks execution time
Daniel Simon wrote: > On Thu, 07 Jun 2007 19:44:47 +0200 > Jan Kiszka <[EMAIL PROTECTED]> wrote: > > Hello, opening a new thead forking from the one opened yesterday by Arnaud > Desvages I moved the thread to xenomai-core, hope you don't mind. > >> Hmm, the patch looks like it consequently reimplements existing runtime >> statistics instead of reusing them as a foundation... >> > Yes, might be simpler now. This patch has been done in urgency upon > xenomai 2.1 and was more or less sleeping since one year. It has been weakly This explains why your changes are right below the xnstat infrastructure code... > tested, only on Pentium 3 cpus. > >> Anyway, I think we could discuss some API extension of Xenomai (for >> native, probably via ). Likely we would keep this report >> optional, ie. make it return -1 or so if CONFIG_XENO_OPT_STATS is off. >> Tracking stats is not as costly as other instrumentations, but it's also >> not free. If you are interested, let us know. It won't be a one-liner, >> but it doesn't look like it has to be as invasive as your approach. > > Our goal is computing the accumulated cost of some selected real-time tasks > to get an image of the cpu load. > > What we need is a record of the accumulated execution time of the > rt_tasks (not the response time, hence the instants when the task is > preempted or suspended must not be counted). > This record must be accessible at any time, either from the calling > task or by another one. > > Our current patch only does that for tasks running in primary mode (and > moreover the measure seems not correctly updated for the calling > task record). > > Thus we would be very happy to get an improved instrumentation api. > I understand that xnstat_runtime_update() handles the measure we need? It was designed to collect precise runtime statistics to be displayed in /proc/xenomai/stat. We would just have to keep a total counter for each task as dumping /proc resets the statistics ATM. > Making it available, e.g. via a rt_task_inquire call, would be great! Well, the best (==most comfortable :o) ) way from my POV would be if you could try rebasing your work on your own first. Questions, even on minor details, are always welcome, review on patches will be provided. Should be no problem to get this into Xenomai 2.4. The rough to-do list would be: o add some persistent runtimer counter to xnthread::stat and maintain it o introduce an xnpod service (inline function) to obtain it (let that thing return [0..LONGLONG_MAX] when stats are available, -1 otherwise) o export the runtime via struct rt_task_info, maybe also the task start time Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
