Latency problem at any process termination

QNX Newsgroups (Archives) qdn.public.qnx4
1

We are using QNX 4.25 Patch D in our product. The processor is
a Pentium II at 400 MHz.

We investigated about a problem in our driver (a PCI card working
in Bus Master) under stress condition that happened repeatedly when
any other not correlated process terminates.

We experimented that the process termination performed by the OS
causes a latency problem in our driver that work at priority 27.

The driver is triggered by a proxy from an ISR; the events from
the card are not served within a reasonable time limit; a queue
is filled up to the end; the size of the queue let me have an
estimation of latency.

The latency seems to be proportional to the amount of allocated
memory, the trouble is that we experimented more that 5 ms
(milliseconds), when the OS has to release about 1.5 Mb of memory.

I cannot say if this latency is due to an interrupt that remains
disabled or Proc last running too much time at priority 30.

Obviously this behavior is not reasonable with such processing
power and a real-time OS, so I am supposing it is the effect
of a bug in the kernel.

We have already spent several days of work to isolate the problem,
so I would like a quick response to this question. In case our
supposition is not true I am ready to pay the $ 200 for your
support, otherwise I think that you are debtors.

Best regards

–

| Enrico Bendinelli | Prisma Engineering srl |
| enricob@prisma-eng.it | Via Petrocchi 4 20127 MILANO ITALY |
| http://www.prisma-eng.it | Tel. +39 02 26113507 Fax. 26113597 |

2

enricob <enricob@prisma-eng.it> wrote:

We are using QNX 4.25 Patch D in our product. The processor is
a Pentium II at 400 MHz.

We investigated about a problem in our driver (a PCI card working
in Bus Master) under stress condition that happened repeatedly when
any other not correlated process terminates.

We experimented that the process termination performed by the OS
causes a latency problem in our driver that work at priority 27.

The driver is triggered by a proxy from an ISR; the events from
the card are not served within a reasonable time limit; a queue
is filled up to the end; the size of the queue let me have an
estimation of latency.

The latency seems to be proportional to the amount of allocated
memory, the trouble is that we experimented more that 5 ms
(milliseconds), when the OS has to release about 1.5 Mb of memory.

When the OS “releases” memory, it all has to be cleared (set to 0).
That is most likely what is chewing up the CPU time.

I cannot say if this latency is due to an interrupt that remains
disabled or Proc last running too much time at priority 30.

First thing to try – you can (and should) drop Proc’s priority.
Use the -P option to Proc32 (you will need to rebuild your OS &
reboot) to drop the priority of Proc32, can go as low as 26, and
then run the really critical real-time processes above Proc’s
priority.

Obviously this behavior is not reasonable with such processing
power and a real-time OS, so I am supposing it is the effect
of a bug in the kernel.

No, this is not a bug in the kernel – when you configured your system,
by leaving Proc32 at priority 30, you said that its work is the most
important thing in the system. Use the priority system to your advantage,
pre-empt Proc32 when you need to.

-David

We have already spent several days of work to isolate the problem,
so I would like a quick response to this question. In case our
supposition is not true I am ready to pay the $ 200 for your
support, otherwise I think that you are debtors.

Best regards

–

| Enrico Bendinelli | Prisma Engineering srl |
| > enricob@prisma-eng.it > | Via Petrocchi 4 20127 MILANO ITALY |
| > http://www.prisma-eng.it > | Tel. +39 02 26113507 Fax. 26113597 |

3

Hey David, just a half-baked thought here, but it seems to me kinda silly to
have a heavyweight process like Proc doing something mundane like zeroing huge
chunks of memory. Is it even remotely possible to have Proc do something like
this instead:

When a process terminates, where Proc would normally zero out the memory, could
you have a very tiny system process that runs at a lower priority that “takes
over” the memory and zeros it on behalf of Proc and lets Proc know when it’s
finished?

These things are always simple when looked at from a distance so I don’t hold
much hope for it being a simple thing to do, but it just seemed to me like some
low priority process could be in charge of cleaning up when a process dies.
You could call it the “reaper”. The other option would be a switch that turns
off the zeroing feature, as I assume it’s just a security measure. Such a
tradeoff might be acceptable for certain situations.

Okay, now you can explain why those are bad ideas… :slight_smile:

-Warren


“David Gibbs” <dagibbs@qnx.com> wrote in message
news:8ucn3r$svs$1@nntp.qnx.com…
| enricob <enricob@prisma-eng.it> wrote:
| > We are using QNX 4.25 Patch D in our product. The processor is
| > a Pentium II at 400 MHz.
|
| > We investigated about a problem in our driver (a PCI card working
| > in Bus Master) under stress condition that happened repeatedly when
| > any other not correlated process terminates.
|
| > We experimented that the process termination performed by the OS
| > causes a latency problem in our driver that work at priority 27.
|
| > The driver is triggered by a proxy from an ISR; the events from
| > the card are not served within a reasonable time limit; a queue
| > is filled up to the end; the size of the queue let me have an
| > estimation of latency.
|
| > The latency seems to be proportional to the amount of allocated
| > memory, the trouble is that we experimented more that 5 ms
| > (milliseconds), when the OS has to release about 1.5 Mb of memory.
|
| When the OS “releases” memory, it all has to be cleared (set to 0).
| That is most likely what is chewing up the CPU time.
|
| > I cannot say if this latency is due to an interrupt that remains
| > disabled or Proc last running too much time at priority 30.
|
| First thing to try – you can (and should) drop Proc’s priority.
| Use the -P option to Proc32 (you will need to rebuild your OS &
| reboot) to drop the priority of Proc32, can go as low as 26, and
| then run the really critical real-time processes above Proc’s
| priority.
|
| > Obviously this behavior is not reasonable with such processing
| > power and a real-time OS, so I am supposing it is the effect
| > of a bug in the kernel.
|
| No, this is not a bug in the kernel – when you configured your system,
| by leaving Proc32 at priority 30, you said that its work is the most
| important thing in the system. Use the priority system to your advantage,
| pre-empt Proc32 when you need to.
|
| -David
|
| > We have already spent several days of work to isolate the problem,
| > so I would like a quick response to this question. In case our
| > supposition is not true I am ready to pay the $ 200 for your
| > support, otherwise I think that you are debtors.
|
| > Best regards
|
| > –
| > -----------------------------------------------------------------
| > | Enrico Bendinelli | Prisma Engineering srl |
| > | enricob@prisma-eng.it | Via Petrocchi 4 20127 MILANO ITALY |
| > | http://www.prisma-eng.it | Tel. +39 02 26113507 Fax. 26113597 |
| > -----------------------------------------------------------------

4

Why the system has to clear all the released memory, that is
currently not used at the moment ? Beauty or aesthetic problem ?

David Gibbs wrote:

enricob <> enricob@prisma-eng.it> > wrote:
We are using QNX 4.25 Patch D in our product. The processor is
a Pentium II at 400 MHz.

We investigated about a problem in our driver (a PCI card working
in Bus Master) under stress condition that happened repeatedly when
any other not correlated process terminates.

We experimented that the process termination performed by the OS
causes a latency problem in our driver that work at priority 27.

The driver is triggered by a proxy from an ISR; the events from
the card are not served within a reasonable time limit; a queue
is filled up to the end; the size of the queue let me have an
estimation of latency.

The latency seems to be proportional to the amount of allocated
memory, the trouble is that we experimented more that 5 ms
(milliseconds), when the OS has to release about 1.5 Mb of memory.

When the OS “releases” memory, it all has to be cleared (set to 0).
That is most likely what is chewing up the CPU time.

I cannot say if this latency is due to an interrupt that remains
disabled or Proc last running too much time at priority 30.

First thing to try – you can (and should) drop Proc’s priority.
Use the -P option to Proc32 (you will need to rebuild your OS &
reboot) to drop the priority of Proc32, can go as low as 26, and
then run the really critical real-time processes above Proc’s
priority.

Obviously this behavior is not reasonable with such processing
power and a real-time OS, so I am supposing it is the effect
of a bug in the kernel.

No, this is not a bug in the kernel – when you configured your system,
by leaving Proc32 at priority 30, you said that its work is the most
important thing in the system. Use the priority system to your advantage,
pre-empt Proc32 when you need to.

-David

We have already spent several days of work to isolate the problem,
so I would like a quick response to this question. In case our
supposition is not true I am ready to pay the $ 200 for your
support, otherwise I think that you are debtors.

Best regards

–

| Enrico Bendinelli | Prisma Engineering srl |
| > enricob@prisma-eng.it > | Via Petrocchi 4 20127 MILANO ITALY |
| > http://www.prisma-eng.it > | Tel. +39 02 26113507 Fax. 26113597 |

–

| Enrico Bendinelli | Prisma Engineering srl |
| enricob@prisma-eng.it | Via Petrocchi 4 20127 MILANO ITALY |
| http://www.prisma-eng.it | Tel. +39 02 26113507 Fax. 26113597 |

5

Warren Peece <warren@nospam.com> wrote:

Hey David, just a half-baked thought here, but it seems to me kinda silly to
have a heavyweight process like Proc doing something mundane like zeroing huge
chunks of memory. Is it even remotely possible to have Proc do something like
this instead:

When a process terminates, where Proc would normally zero out the memory, could
you have a very tiny system process that runs at a lower priority that “takes
over” the memory and zeros it on behalf of Proc and lets Proc know when it’s
finished?

I remember have thoughts like this too, a few years back, and discussing
them with Steve McPolin. I had actually thought to suggest have idle
do it. He had reasons why this could be a problem, but I don’t remember
what the actual reasons were.

At this point in the life of QNX4, though, I don’t see anything like this
as being at all likely to be changed – at minimum it could introduce
possible stability issues.

Now, how QNX Neutrino handles memory release might be a topic worth
raising in the Neutrino conferences…

These things are always simple when looked at from a distance so I don’t hold
much hope for it being a simple thing to do, but it just seemed to me like some
low priority process could be in charge of cleaning up when a process dies.
You could call it the “reaper”. The other option would be a switch that turns
off the zeroing feature, as I assume it’s just a security measure. Such a
tradeoff might be acceptable for certain situations.

I don’t think it is “just” security issues – I can’t say that there
isn’t code somewhere that depends on memory newly allocated from the
system being zeroed.

-David

6

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:8ucogl$qi$1@nntp.qnx.com…

Warren Peece <> warren@nospam.com> > wrote:
Hey David, just a half-baked thought here, but it seems to me kinda
silly to
have a heavyweight process like Proc doing something mundane like
zeroing huge
chunks of memory. Is it even remotely possible to have Proc do
something like
this instead:

When a process terminates, where Proc would normally zero out the
memory, could
you have a very tiny system process that runs at a lower priority that
“takes
over” the memory and zeros it on behalf of Proc and lets Proc know when
it’s
finished?

I remember have thoughts like this too, a few years back, and discussing
them with Steve McPolin. I had actually thought to suggest have idle
do it. He had reasons why this could be a problem, but I don’t remember
what the actual reasons were.

At this point in the life of QNX4, though, I don’t see anything like this
as being at all likely to be changed – at minimum it could introduce
possible stability issues.

Now, how QNX Neutrino handles memory release might be a topic worth
raising in the Neutrino conferences…

When 2.0 came out, I was told memory clean up was done at priority 15.
I was also told the kernal group was looking into change it so it’s done
at the priority of the process.

These things are always simple when looked at from a distance so I don’t
hold
much hope for it being a simple thing to do, but it just seemed to me
like some
low priority process could be in charge of cleaning up when a process
dies.
You could call it the “reaper”. The other option would be a switch that
turns
off the zeroing feature, as I assume it’s just a security measure. Such
a
tradeoff might be acceptable for certain situations.

I don’t think it is “just” security issues – I can’t say that there
isn’t code somewhere that depends on memory newly allocated from the
system being zeroed.

-David

7

“enricob” <enricob@prisma-eng.it> wrote in message
news:3A09E3C4.30C85426@prisma-eng.it…

Why the system has to clear all the released memory, that is
currently not used at the moment ? Beauty or aesthetic problem ?

One of the reason is security, you don’t want to have the passwd program
lease the user/password in memory so that any non root program can
attempt to read it. A bit paranoid in a systeme like QNX4 since it’s
mostly for embedded system.

I remember a while ago I made the suggestion that Proc32 could
have an option to enable/disable memory clean up depending on the
level of security that is required.

  • Mario
8

Yeah, I was trying to think of a “non-invasive” way of getting this done.
One thought I had was that once a process dies, instead of just cleaning it
up, could the kernel stuff the zeroing code into the CS (which would use no
stack and be quite small, having had the actual memory ranges to zero
stuffed by the kernel), reset the IP and “bring the dead process back to
life” on its new mission of clearing its own memory? Once the process died
a second time, the kernel would only need zero the small portion of code
that did the zeroing previously. I realize that adds a few extra steps to
the whole death procedure, but perhaps there’s a certain memory size where
the kernel could decide it’s more efficient to do those extra steps, and
anything smaller would just terminate “normally”. Then again if development
on QNX4 is frozen, it’s a moot point (a “mute” point as our marketing guy
would say…)

-Warren


“David Gibbs” <dagibbs@qnx.com> wrote in message
news:8ucogl$qi$1@nntp.qnx.com…

Warren Peece <> warren@nospam.com> > wrote:
Hey David, just a half-baked thought here, but it seems to me kinda
silly to
have a heavyweight process like Proc doing something mundane like
zeroing huge
chunks of memory. Is it even remotely possible to have Proc do
something like
this instead:

When a process terminates, where Proc would normally zero out the
memory, could
you have a very tiny system process that runs at a lower priority that
“takes
over” the memory and zeros it on behalf of Proc and lets Proc know when
it’s
finished?

I remember have thoughts like this too, a few years back, and discussing
them with Steve McPolin. I had actually thought to suggest have idle
do it. He had reasons why this could be a problem, but I don’t remember
what the actual reasons were.

At this point in the life of QNX4, though, I don’t see anything like this
as being at all likely to be changed – at minimum it could introduce
possible stability issues.

Now, how QNX Neutrino handles memory release might be a topic worth
raising in the Neutrino conferences…

These things are always simple when looked at from a distance so I don’t
hold
much hope for it being a simple thing to do, but it just seemed to me
like some
low priority process could be in charge of cleaning up when a process
dies.
You could call it the “reaper”. The other option would be a switch that
turns
off the zeroing feature, as I assume it’s just a security measure. Such
a
tradeoff might be acceptable for certain situations.

I don’t think it is “just” security issues – I can’t say that there
isn’t code somewhere that depends on memory newly allocated from the
system being zeroed.

-David

9

enricob <enricob@prisma-eng.it> wrote:

Why the system has to clear all the released memory, that is
currently not used at the moment ? Beauty or aesthetic problem ?

Discussed that elsewhere
– security
– programs may depend on it, as it is expected behaviour

-David

David Gibbs wrote:

enricob <> enricob@prisma-eng.it> > wrote:
We are using QNX 4.25 Patch D in our product. The processor is
a Pentium II at 400 MHz.

We investigated about a problem in our driver (a PCI card working
in Bus Master) under stress condition that happened repeatedly when
any other not correlated process terminates.

We experimented that the process termination performed by the OS
causes a latency problem in our driver that work at priority 27.

The driver is triggered by a proxy from an ISR; the events from
the card are not served within a reasonable time limit; a queue
is filled up to the end; the size of the queue let me have an
estimation of latency.

The latency seems to be proportional to the amount of allocated
memory, the trouble is that we experimented more that 5 ms
(milliseconds), when the OS has to release about 1.5 Mb of memory.

When the OS “releases” memory, it all has to be cleared (set to 0).
That is most likely what is chewing up the CPU time.

I cannot say if this latency is due to an interrupt that remains
disabled or Proc last running too much time at priority 30.

First thing to try – you can (and should) drop Proc’s priority.
Use the -P option to Proc32 (you will need to rebuild your OS &
reboot) to drop the priority of Proc32, can go as low as 26, and
then run the really critical real-time processes above Proc’s
priority.

Obviously this behavior is not reasonable with such processing
power and a real-time OS, so I am supposing it is the effect
of a bug in the kernel.

No, this is not a bug in the kernel – when you configured your system,
by leaving Proc32 at priority 30, you said that its work is the most
important thing in the system. Use the priority system to your advantage,
pre-empt Proc32 when you need to.

-David

We have already spent several days of work to isolate the problem,
so I would like a quick response to this question. In case our
supposition is not true I am ready to pay the $ 200 for your
support, otherwise I think that you are debtors.

Best regards

–

| Enrico Bendinelli | Prisma Engineering srl |
| > enricob@prisma-eng.it > | Via Petrocchi 4 20127 MILANO ITALY |
| > http://www.prisma-eng.it > | Tel. +39 02 26113507 Fax. 26113597 |

–

| Enrico Bendinelli | Prisma Engineering srl |
| > enricob@prisma-eng.it > | Via Petrocchi 4 20127 MILANO ITALY |
| > http://www.prisma-eng.it > | Tel. +39 02 26113507 Fax. 26113597 |

10

David Gibbs wrote:

enricob <> enricob@prisma-eng.it> > wrote:
Why the system has to clear all the released memory, that is
currently not used at the moment ? Beauty or aesthetic problem ?

Discussed that elsewhere
– security

We chose QNX because we appreciated its Real Time features, together
with compatibility with Posix world that facilitate development and
testing. We use it in vertical applications, and I have never heard
about people that are using it as a corporate network OS.

In the QNX world real time performances are much more important
then security aspects.


– programs may depend on it, as it is expected behaviour

The start-up code of any application has the task to properly
initialize static memory at the one’s priority with well known
rules about, other rules exists about initial state of allocated
dynamic memory.

If a program depends on it in the wrong section, it must be corrected.

I am really surprised of this discussion, please let me known if
similar approaches were used in other parts of the OS.

Please let us have a switch to disable such useless and harmful
feature in most cases.

Thanks
Enrico

-David

David Gibbs wrote:

enricob <> enricob@prisma-eng.it> > wrote:
We are using QNX 4.25 Patch D in our product. The processor is
a Pentium II at 400 MHz.

We investigated about a problem in our driver (a PCI card working
in Bus Master) under stress condition that happened repeatedly when
any other not correlated process terminates.

We experimented that the process termination performed by the OS
causes a latency problem in our driver that work at priority 27.

The driver is triggered by a proxy from an ISR; the events from
the card are not served within a reasonable time limit; a queue
is filled up to the end; the size of the queue let me have an
estimation of latency.

The latency seems to be proportional to the amount of allocated
memory, the trouble is that we experimented more that 5 ms
(milliseconds), when the OS has to release about 1.5 Mb of memory.

When the OS “releases” memory, it all has to be cleared (set to 0).
That is most likely what is chewing up the CPU time.

I cannot say if this latency is due to an interrupt that remains
disabled or Proc last running too much time at priority 30.

First thing to try – you can (and should) drop Proc’s priority.
Use the -P option to Proc32 (you will need to rebuild your OS &
reboot) to drop the priority of Proc32, can go as low as 26, and
then run the really critical real-time processes above Proc’s
priority.

Obviously this behavior is not reasonable with such processing
power and a real-time OS, so I am supposing it is the effect
of a bug in the kernel.

No, this is not a bug in the kernel – when you configured your system,
by leaving Proc32 at priority 30, you said that its work is the most
important thing in the system. Use the priority system to your advantage,
pre-empt Proc32 when you need to.

-David

We have already spent several days of work to isolate the problem,
so I would like a quick response to this question. In case our
supposition is not true I am ready to pay the $ 200 for your
support, otherwise I think that you are debtors.

Best regards

–

–

| Enrico Bendinelli | Prisma Engineering srl |
| enricob@prisma-eng.it | Via Petrocchi 4 20127 MILANO ITALY |
| http://www.prisma-eng.it | Tel. +39 02 26113507 Fax. 26113597 |

11

“enricob” <enricob@prisma-eng.it> wrote in message
news:3A0B3443.DEFEF6FA@prisma-eng.it…

David Gibbs wrote:

enricob <> enricob@prisma-eng.it> > wrote:
Why the system has to clear all the released memory, that is
currently not used at the moment ? Beauty or aesthetic problem ?

Discussed that elsewhere
– security

We chose QNX because we appreciated its Real Time features, together
with compatibility with Posix world that facilitate development and
testing. We use it in vertical applications, and I have never heard
about people that are using it as a corporate network OS.

In the QNX world real time performances are much more important
then security aspects.


– programs may depend on it, as it is expected behaviour

The start-up code of any application has the task to properly
initialize static memory at the one’s priority with well known
rules about, other rules exists about initial state of allocated
dynamic memory.

If a program depends on it in the wrong section, it must be corrected.

I am really surprised of this discussion, please let me known if
similar approaches were used in other parts of the OS.

Please let us have a switch to disable such useless and harmful
feature in most cases.

The guy that wrote the kernel was (and still is ) a very very smart
guy. There must be a very good reason why it’s there. Maybe
it could be improve but to call it a “useless and harmfull feature”
is IHMO an overstatement.

There are other reality then yours… ( Wow I like the sound of that, I
came
up with this myself )

12

Mario Charest wrote:

There are other reality then yours… ( Wow I like the sound of that, I
came
up with this myself )

Nah, you heard it somewhere before and forgot. It’s somewhat of a
paraphrase of this line from Shakespeare’s Hamlet:

“There are more things in heaven and earth, Horatio, than are dreamt of in
your philosophy.”

;0)

13

“J. Scott Franko” <jsfranko@switch.com> wrote in message
news:3A0C6F78.BC936EBB@switch.com…

Mario Charest wrote:

snip

There are other reality then yours… ( Wow I like the sound of that, I
came
up with this myself )

Nah, you heard it somewhere before and forgot. It’s somewhat of a
paraphrase of this line from Shakespeare’s Hamlet:

“There are more things in heaven and earth, Horatio, than are dreamt of in
your philosophy.”

So that’s it, i’m the reincarnation of Shakespeare!

;0)

14

Mario Charest wrote:

“enricob” <> enricob@prisma-eng.it> > wrote in message
news:> 3A0B3443.DEFEF6FA@prisma-eng.it> …
David Gibbs wrote:

enricob <> enricob@prisma-eng.it> > wrote:
Why the system has to clear all the released memory, that is
currently not used at the moment ? Beauty or aesthetic problem ?

Discussed that elsewhere
– security

We chose QNX because we appreciated its Real Time features, together
with compatibility with Posix world that facilitate development and
testing. We use it in vertical applications, and I have never heard
about people that are using it as a corporate network OS.

In the QNX world real time performances are much more important
then security aspects.


– programs may depend on it, as it is expected behaviour

The start-up code of any application has the task to properly
initialize static memory at the one’s priority with well known
rules about, other rules exists about initial state of allocated
dynamic memory.

If a program depends on it in the wrong section, it must be corrected.

I am really surprised of this discussion, please let me known if
similar approaches were used in other parts of the OS.

Please let us have a switch to disable such useless and harmful
feature in most cases.

The guy that wrote the kernel was (and still is ) a very very smart
guy. There must be a very good reason why it’s there. Maybe
it could be improve but to call it a “useless and harmfull feature”
is IHMO an overstatement.

I have never had any doubt about the professional ability of the guys
that wrote QNX kernel, that we are using in our products and promoting
to our customers.

But you cannot ask me to accept quietly this fact that is evidently
in contrast with the main and the best feature of QNX: low latency time
and high performances.

We develop simulators for telecom market and often our applications
require a lot of memory. Multiple applications can work concurrently.

We experimented that every 1 Mb of released memory causes a latency of
about 3 ms. An application of ours allocates 24 Mb, when it terminates
the activity of the system stops for 24*3 = 72 ms.

Do you think that this behavior is normal for a real time system ?

After we have clarified the fact, now I able to understand some
occasional
problems, that we had in the past, and we were not able to explain after
much work and some embarrassing with our customers.

Perhaps did we forget to read any document ?

We followed the suggestion of David and our main concern was solved
immediately, but what about the effects towards the other devices and
applications under heavy load conditions ?

Are you so certain we will not have any other problem caused by that ?

There are other reality then yours… ( Wow I like the sound of that, I
came
up with this myself )

All the realities have the right to exists and anyone must take
the own responsibilities and respect the work of the others.

–

| Enrico Bendinelli | Prisma Engineering srl |
| enricob@prisma-eng.it | Via Petrocchi 4 20127 MILANO ITALY |
| http://www.prisma-eng.it | Tel. +39 02 26113507 Fax. 26113597 |

15

David, if I mmap() in a whole slug of memory, then munmap() it before exiting,
what process does the memory cleaning in that instance? If it’s not Proc, then
perhaps this might be a way for people to avoid the latency involved with the
standard malloc() routines at process termination…

-Warren


“David Gibbs” <dagibbs@qnx.com> wrote in message
news:8ucn3r$svs$1@nntp.qnx.com…
|
| When the OS “releases” memory, it all has to be cleared (set to 0).
| That is most likely what is chewing up the CPU time.

16

Warren Peece <warren@nospam.com> wrote:

David, if I mmap() in a whole slug of memory, then munmap() it before exiting,
what process does the memory cleaning in that instance? If it’s not Proc, then
perhaps this might be a way for people to avoid the latency involved with the
standard malloc() routines at process termination…

Proc does that cleanup as well.

-David

17

enricob <enricob@prisma-eng.it> wrote:

I don’t know why the original design decision to implement process
cleanup was done this way – I just know when I asked Steve about
changing it, he said there were problems with changing it. That
was quite a long way into the life of the product, and I can understand
not changing.

Why the initial decision was made – I don’t know. Among the considerations
may have been one of focus – in many embedded/realtime systems the loading
or termination of a process is an unusual event – they very often have an
initialization process, then run without any change in which processes are
active for a long time, then, get taken down for maintenance. I think this
sort of environment was in mind in the initial design of the OS, and that
may have biased some choices, that became less scalable. Who had ever
heard of a 3M process in the mid 80s? Well maybe, but running on a
PC? Running on an embedded PC?

Over time, we found that some of the things that the Process manager did
could interfere with the realtime response of the system, so we added the
option to drop the priority of the process manager and run the critical
real-time processes at a higher priority.

I know that in Neutrino, this (memory cleanup) was implemented differently.
(At least, I think so – it is my understanding that cleanup is still done
by a thread in the process manager, but that it is done at the priority of
the exiting process.)

Sometimes we find limitation or, even, mistakes in an earlier design. We
try to incorporate the best of the old, along with the new, and what we’ve
learned along the way in each succeeding generation of the QNX OS.

-David

18

So it looks like the best workaround other than changing the priority of Proc
would be to mmap() in memory in relatively small chunks, then free them one at
a time perhaps with some delay in between. This won’t get rid of the problem,
but it will spread it out enough so that it wouldn’t interfere with other
processes as much.

-Warren


“David Gibbs” <dagibbs@qnx.com> wrote in message
news:8upota$qu1$1@nntp.qnx.com…
| Warren Peece <warren@nospam.com> wrote:
| > David, if I mmap() in a whole slug of memory, then munmap() it before
exiting,
| > what process does the memory cleaning in that instance? If it’s not Proc,
then
| > perhaps this might be a way for people to avoid the latency involved with
the
| > standard malloc() routines at process termination…
|
| Proc does that cleanup as well.
|
| -David

19

Thank you for your final clarification.

The priority change of Proc solved our main issue, and
we have generally increased buffering in order to prevent
possible other problems.

We have already planned to start porting of our software
towards Neutrino in the near future.

\

| Enrico Bendinelli | Prisma Engineering srl |
| enricob@prisma-eng.it | Via Petrocchi 4 20127 MILANO ITALY |
| http://www.prisma-eng.it | Tel. +39 02 26113507 Fax. 26113597 |

20

When the OS “releases” memory, it all has to be cleared (set to 0).
That is most likely what is chewing up the CPU time.

I cannot say if this latency is due to an interrupt that remains
disabled or Proc last running too much time at priority 30.

First thing to try – you can (and should) drop Proc’s priority.
Use the -P option to Proc32 (you will need to rebuild your OS &
reboot) to drop the priority of Proc32, can go as low as 26, and
then run the really critical real-time processes above Proc’s
priority.

Obviously this behavior is not reasonable with such processing
power and a real-time OS, so I am supposing it is the effect
of a bug in the kernel.

No, this is not a bug in the kernel – when you configured your system,
by leaving Proc32 at priority 30, you said that its work is the most
important thing in the system. Use the priority system to your advantage,
pre-empt Proc32 when you need to.

-David

Does Proc32 handle messages while it’s doing this housecleaning? If not,
what system calls produce messages to Proc32? Just raising my process’
priority won’t help if it ends up send-blocked on proc.

Thanks,
Marty Doane