News Forum Phone database

> New Topic
> Reply
< Esato Forum Index > Sony Ericsson / Sony > Symbian phones > Demand Paging for UIQ3 would you want it now? Bookmark topic



Yeah i know that, but my point is that i'm not talking about official se developer's interest to reborn the P990 firmware adventures but instead SE should open source the P990's firmware to the opensource community then perhaps the latter could make demand paging possible for the P990 firmware and given the number advantage UIQ Open source community had over the SE UIQ developers that would not be far from reality if that happens
--
Posted: 2007-12-08 12:28:49
Edit : Quote


@makbil...

precisely !


--
Posted: 2007-12-08 12:36:04
Edit : Quote



*Grumble*.. It doesn't work like that. And I'll go through it one more time, so noone can say they don't understand.

Demand paging on a mobile phone:

1. program is loaded into memory, and collections of resources will be needed. These are called /libraries/. And are indirectly referenced in the running program.
2. To access the information in the libraries, some parsing is needed. Meaning that the phone needs time and cpu time to find the right resource.
3. The question here is what sort of strategy should be used to find or optionally keep the resources. So far, most mobile units have used these strategies: read the immediately needed parts, use a form of prediction, or else load into memory what is specifically requested. Any indirect references would then be junked after the operation was done.
4. But this is not very efficient if the program runs all the time, instead of just once in a while.
5. So alternatives to that is either to load the entire program into faster ram, and everything that might be needed, under the presumption that the parsing would be quicker than pre- loading (which it tends to be on small programs). Or optionally load parts of the program into faster ram, and keep the references in memory available for use (for at least the program that requested it). That last one is called /demand paging/. And there are several variants of the implementations. (Other than that, all processors will use a form of indirect addressing for the fastest cache, which would be about the same, but let's not get into that).

The question here is about two things: what will save more ram and resources. And what will make the system more stable and predictable. And this, unfortunately, is not an either/or case.

It's not like it's going to automatically increase performance for a program if every time a new object is created, it has to be loaded from flash- ram instead of the working ram. Which could easily happen. And it's not like loading a large database that will be read maximum one time is going to save run- time operations. In the same way, there's a reason any device made on top of dll- hell architecture is not stable.

So again, it depends. But it depends on the kind of use that means individual users might actually be able to predict what sort of improvement they might get, like suggested above. It also depends on the size of the ram loaded initially is, and whether the individual ram- operations grow exponentially during run- time. Which, depending on implementation, can happen with or without demand- paging of course.

Are we properly confused now? Very good! Happy to help.


edit: ...while we're talking about it anyway - anyone want to take a guess at why one symbiansigned test is about consistency (that memory use does not grow during program- execution)?
_________________
The p1 Whiki

[ This Message was edited by: Nipsen on 2007-12-08 13:10 ]
--
Posted: 2007-12-08 14:05:49
Edit : Quote




1. Even if you have big enough RAM, demand paging is still beneficial - i.e. program starts up faster giving the user a sense of speed. The OS may spend more cpu cycles predicting which are next pages to load. A page map can be pregenerated (with programmers input) to assist in this. (And all this prediction can be done during low cpu cycle)

2. For most big apps, a big proportion of codes are never used. So why waste battery loading the unused codes into "limited" RAM to be discarded later.


--
Posted: 2007-12-08 15:06:37
Edit : Quote


Yeah. It's possible to imagine a scenario where you would get a shorter initial load, and that the includes used often would result in less ram used. And the larger one- shot resources could just be thrown away on the few occasions they would be needed. And that would produce a smaller ram- print and about the same response, with occasional slowdowns slightly longer than usual on places that you would probably expect a slowdown anyway.

But. It's also possible to imagine a scenario where every time the program does an operation, you would experience a slowdown, together with slower and interrupted read from the flash- disk or the modem (because the increased amount of background operations). Which would leave the idle- level on the processor high, even between operations, as well as require constant access to the flash- rom, where this would not have been needed otherwise. It's also possible that on a complex program, where all resources would be used, the final ram- print would be bigger because of overhead. Not to mention that context- switches would be painfully slow, because the consistency of the memory would have to be checked and stored every time.

In other words - the trick would be to construct your programs to fit with the ideal scenario, as far as this is possible. And I have no doubt that the s60 people found out it was beneficial for them on their setup. But - if you accept that there may be other scenarios that are possible - this might not be an optimal solution on other systems. If they for instance have slower processors and bigger ram, etc. It might even be the case that it's a special case on s60, because of the way the feature pack is constructed - and that for any other similar system without indirect addressing, virtual ram and so on, it would be useless to even consider designing a general memory manager like this. Specially because, as I said, we're not talking about a desktop system.
--
Posted: 2007-12-08 19:53:52
Edit : Quote


@Nipsen

It really doesn't matter what you want to say about dynamic libraries etc the very simple fact is this,

Users of the original N95 that now have Demand Paging experience a faster boot start time a faster and smoother OS and have gained 50% more Ram than they previously had. The have also seen additional run time from their battery even if it is only approx 20% and not 25% it is still an improvement. All of this has to be positive there really is no negatives with it all.


So when you say this

"The question here is about two things: what will save more ram and resources. And what will make the system more stable and predictable. And this, unfortunately, is not an either/or case."

You are quite simply wrong as it does achieve both of these things at once and in the N95 8gb it means it boots faster and has more Ram and a faster performing OS and also again increases Battery life with no negative effect on stability of the OS and again how can any of this be bad?.

So just how is the advancement of the Symbian OS with Demand Paging now rather than later not a good thing then?

As for this statement

"while we're talking about it anyway - anyone want to take a guess at why one symbiansigned test is about consistency (that memory use does not grow during program- execution)?"

Please tell us because whilst this what the test may mean to do it most certainly is not the experience of P990 users that suffered from memory leaks is it? so this test obviously doesn't apply to all devices when they are actually running in the real world then.

Marc




_________________
Nokia N95 8GB, SU-8W, Fring, Vox, Tom Tom 6, Shure EC2g
Honoured to have won BEST DEBATER

[ This Message was edited by: Dogmann on 2007-12-08 19:40 ]
--
Posted: 2007-12-08 20:38:23
Edit : Quote


@razec, I agree with you but SE has clearly shown that they couldn't care less. Besides, it is not even entirely up to SE to make the OS open source as it does not belong to them, they license both Symbian and UIQ.
--
Posted: 2007-12-08 20:56:55
Edit : Quote


Let's work on a less confusing description of demand paging:

In operating systems, demand paging is an application of virtual memory. In a system that uses demand paging, the operating system copies a disk page into physical memory only if an attempt is made to access it (i.e., if a page fault occurs). It follows that a process begins execution with none of its pages in physical memory, and many page faults will occur until most of a process's working set of pages is located in physical memory.

Going by this definition, devices with limited RAM, such as the P990, will definitely benefit from demand paging. Simply, there will be more memory available with the same number of programs running and the OS will not have to spend time closing unused programs to free RAM for running new programs. In fact, waiting time will be distributed more evenly, programs will start faster but will execute a little slower. This is definitely desired for a multitasking OS. I'm not entirely sure but the battery conservation may be due to applications not being closed and opened. Probably page swapping consumes less juice than starting and terminating applications with all the linked libraries that have to be reopened.


--
Posted: 2007-12-08 22:10:00
Edit : Quote


But.. when we're talking about fairly small programs and small amounts of ram? ..And a memory manager for rationing out a program that takes around 0,5Mb? On a system that shouldn't inflate the constants on every operation too much?

The extra panels, configurations, and so on already run in separate programs after all - they don't include vast amounts of extra OS functions and libraries, either in context shifts or on startup. so how much do you really save? And how long would it take before you have used the same amount of ram as before?

If there were some objects that were created often and then quickly disposed of that had loads of conditions - graphics, for example, then I might see the point. But we're talking about, most of the time, a memory manager for handling the tiniest amounts of ram..

edit: wasn't very clear on the last point - a memory manager for perhaps one- shot operations.. how useful?
_________________
The p1 Whiki

[ This Message was edited by: Nipsen on 2007-12-08 21:51 ]
--
Posted: 2007-12-08 22:42:06
Edit : Quote


@Nipsen,

Whilst all of what you say may be or may not be true depending on the exact applications in question, it is fairly obvious that if Boot time is decreased by approx 50% and at the same time free Ram on Boot up is also increased by 50% neither of these can be considered small or irrelevant differences.

Also the whole OS operates faster and smoother and there is an increase in battery performance again not an insignificant one one even if at worst it is only another 20%.

If the increases in performance and speed where of no importance and not noticeable i doubt anyone would of bothered implementing them and users would not be pleased to have them either.

This is not based on theoreticals but what actual users have experienced with the increased performance and extra free Ram.

Now whilst for now this has only been applied to some S60 devices that had less of a problem then UIQ3 with Ram and they have seen an extra 50% we can only estimate that the benefits would be similiar if not greater. Maybe as the problem appears worse with UIQ3 the gains would be indeed be greater, but currently we won't know until SE implements it in a newer version of UIQ.

Marc

_________________
Nokia N95 8GB, SU-8W, Fring, Vox, Tom Tom 6, Shure EC2g
Honoured to have won BEST DEBATER

[ This Message was edited by: Dogmann on 2007-12-08 22:18 ]
--
Posted: 2007-12-08 23:18:29
Edit : Quote

---

New Topic   Reply

Forum Index