SkyOS download version
Robert Szeleney
I uploaded a pre-release version of SkyOS V3.3.4
Please test this version and report any problems.
I will upload a bugfixed version in 1-2 weeks than!
--
Sky Operating System V3
http://www.skyos.org
John Jensen
: I uploaded a pre-release version of SkyOS V3.3.4
: Please test this version and report any problems.
: I will upload a bugfixed version in 1-2 weeks than!
I've started an occaisional weblog, with the description:
I am getting interested in Operating Systems concepts. Perhaps it is
just a counter-culture thing. For every article I find on an interesting
operating system architecture, I find another article on why operating
system architectures don't matter any more.
This log chronicles the interesting bits and pieces I find along the
way.
It is mirrored at my primenet and @home accounts:
http://www.primenet.com/~jjens/FooOS/weblog1.html
http://members.home.com/jjens/FooOS/weblog1.html
I'd like to track what is going on with alternative OSes, and would
appreciate an email from anyone with news.
This isn't meant to be a directory (several excellent ones exist), just a
... weblog.
John
--
33° 39' 42N 117° 45' 06W
Michael Zandstra
learn from a OS that has been so far developed.
And an licence? Just for intrests.
Greetz,
Michael.
Martijn Boekhorst
In the log, there's an update on August 6th :
User allocated memory (malloc/sbrk) doesn't get reserved anymore.
But, if the user task accesses allocated memory, a pagefault occures
and the requested memory gets allocated.
Which kinda leaves me wondering : "Why?". Is this faster? do other OS's do
this?
Scott Wood
That would be memory over-committing, which is a Very Bad Thing
inspired by people concerned that they may not be putting every bit
of their swap space to good use (since not all allocated memory will
ever be referenced). The risk of having an out-of-memory condition
when you can't return an error is much, much worse than needing a
little bit more swap space to cover for the never referenced pages.
-Scott
Robert Szeleney
"Martijn Boekhorst" <Mar...@boekhorst.despam-this.net> schrieb im
Newsbeitrag news:9nopc9$7po$1...@news1.xs4all.nl...
Consider an application which allocates 500MB of RAM. If the application
will use only 20MB you allocated 480MB which never will be used. (and which
will not be available physically).
Which this demand paging feature you only allocate memory which really is
needed.
Robert Szeleney
Scott Wood
>Consider an application which allocates 500MB of RAM. If the application
>will use only 20MB you allocated 480MB which never will be used. (and which
>will not be available physically).
>Which this demand paging feature you only allocate memory which really is
>needed.
That application is broken. There's no reason to allocate such a
huge region in advance without knowing whether it is needed or not.
The only wastage that is hard to avoid is in demand-loaded private
file mappings. This is usually used for data areas of executables,
and is usually small enough that throwing a little extra swap space
at it is reasonable.
Now, consider an application that allocates 500MB of RAM. Your
system grants the request, even though you only have, say, 128MB RAM
and 128MB swap. The application then proceeds to actually write data
to enough pages to fill all RAM and swap. What do you do on the next
unallocated page that is accessed? Killing the process is a really
ugly solution, and it's not always as clear as it is in this example
who the memory hog is. OTOH, if the 500MB request fails, the
application can perhaps deal with having less memory, or at worse
return an error to the user in a clean, controlled manner.
-Scott
Robert Szeleney
of free memory available. (Lets say, only 48MB).
The applicatino can't run than.
If you reserved but not allocate this memory, the applicatin think it can
use 50MB ram. Then it filles 48MB (physical RAM is full). Now, it the last
2MB or access, 2other MB are swapped out. You can't do that, if you allocate
50MB at once.
"Scott Wood" <sc...@buserror.net> schrieb im Newsbeitrag
news:slrn9q1qa6...@odin.buserror.net...
Scott Wood
>Ok, but for example the app allocates 50MB of RAM. You haven't such amount
>of free memory available. (Lets say, only 48MB).
>The applicatino can't run than.
That's what swap is for, though the app should have some means of
finding out what sort of working set it can expect to be able to keep
in RAM, so it can tune its behavior accordingly.
>If you reserved but not allocate this memory, the applicatin think it can
>use 50MB ram. Then it filles 48MB (physical RAM is full). Now, it the last
>2MB or access, 2other MB are swapped out. You can't do that, if you allocate
>50MB at once.
Sure. However, the original statement was that the memory wasn't
even reserved, and some mainstream OSes (such as Linux) in fact do
not reserve memory until the actual demand allocation occurs (with
the exception of mlockall(MCL_FUTURE)'ed processes, of course), which
is unfortunate.
-Scott
Robert Szeleney
needed!
"Scott Wood" <sc...@buserror.net> schrieb im Newsbeitrag
news:slrn9q3bau...@odin.buserror.net...
