@AmiDog

Quote:

How about the T: assign which is usually pointing to RAM? Should people be forced to have it on a disk (I wouldn't want that) or should an application fail simply because the RAM-disk gets full (I wouldn't want that either). You've got some points, but I still think the current solution is the best one.

IMHO, is the ideal solution is the second I proposed in my previous post: having a proper RAM disk, like the one we have had until VM arrived, and a temporary disk (or whatever it will be called), like the current RAM disk. That way, users can still use a 100% authentic RAM disk and, at the same time, have a swappable RAM-based disk for T: and other uses. Of course, it would be nice if users could be able to decide whether to mount the RD, the TD or both. And thanks to the Workbench preferences, we could even decide which of them to show on the WB

saimo

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

Sorry for bumping, but I thought that since the issue dealt with here has a certain importance to our beloved OS it would be a pity if the discussion drowned in the (fully justified) SAM+AOS enthusiam flood

saimo

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

I think most people would rather have their computer just work (albeit possibly a little more slowly) than crashing or complaining about running out of memory or having their program/game turn extremely slow because someone somewhere has decided that some large files stored in RAM: that haven't been accessed for several hours mustn't be swapped out for some unknown reason (as a result it may have to swap out to disk some memory area that is used more frequently).

You state as reason that RAM: must be in physical memory but this is nonesense since that same "argument" applies much more so to memory allocated by programs using AllocMem()/AllocVec(), in which case you should simply not create a SWAP partition => your "problem" solved.

Allowing swapping on RAM disk is not only useful for storing large files on RAM: but also useful since clipboard.device stores clips in RAM:Clipboards. Do keep in mind that memory is swapped out on basis of how (in)frequently it is being accessed.

@salass00

I use RAM: for many different reasons, but one of them is to not fill my disks with files, drawers and junk. When I test some new software downloaded I simply put it in RAM;. If for some reason the programs crashes, or it leaves some files open, you can not delete it either because the system froze or because its drawer or some files are being used (opened and not yet closed). When I have it in RAM I don't care about deleting anything especially the drawers. They will go away by themself once I turn off the computer. If I need more physical memory, I just delete some stuff from RAM: If I test software out of Hard disk, I need to care about the clean process after, which takes time. One of the big RAM Disk usages is and always will be about saving time. In its current implementation on AmigaOS 4.1 it does exactly this like before - saves me time.

_________________
Games, programs, reviews

@salass00

Quote:

I think most people would rather have their computer just work (albeit possibly a little more slowly) than crashing or complaining about running out of memory or having their program/game turn extremely slow because someone somewhere has decided that some large files stored in RAM: that haven't been accessed for several hours mustn't be swapped out for some unknown reason (as a result it may have to swap out to disk some memory area that is used more frequently).

Since you basically repeated what others already said, I'll keep it short trying not to repeat myself endlessly.
My proposal of having two devices (a 100% RAM disk and a swappable RAM disk) easily solves the problem you fear.
As for crashing, the OS should not crash just because an out of memory error.

Quote:

You state as reason that RAM: must be in physical memory

I'm not sure how to interpret this, but, anyway, just to make it clear: I explained the reasons why the RAM disk should (and, IMHO, must) be just in physical memory.

Quote:

but this is nonesense since that same "argument" applies much more so to memory allocated by programs using AllocMem()/AllocVec(),

This has already been said and got its answer (which, again, I'm only repeating in short here): it all boils down to the fact that when the user uses the RAM disk, he directly wants to use the RAM, whereas this is not the case when he uses an application.

Quote:

in which case you should simply not create a SWAP partition => your "problem" solved.

For example, one could want to have VM active and, at the same time, the possibility of accessing the RAM being sure that exclusively RAM is used. The solution you propose does not make this not possible. Such a solution is less flexible and thus meets the requirements of less users. The end result is that the OS is not as good as it could have been (BTW, with a very minimal effort, in this case).

Quote:

Allowing swapping on RAM disk is not only useful for storing large files on RAM:

Which, as already explained, is a misuse in first place.

Quote:

but also useful since clipboard.device stores clips in RAM:Clipboards.

I guess that the clipboard.device instead uses CLIPS:, which the user is free to assign to any place in a swappable RAM disk. Again, this problem has a simple and clean solution.

Quote:

Do keep in mind that memory is swapped out on basis of how (in)frequently it is being accessed.

I'm not discussing how good the VM policy is.

saimo

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo
Quote:

IMHO, is the ideal solution is the second I proposed in my previous post: having a proper RAM disk, like the one we have had until VM arrived, and a temporary disk (or whatever it will be called), like the current RAM disk. That way, users can still use a 100% authentic RAM disk and, at the same time, have a swappable RAM-based disk for T: and other uses.

It's senseless, because it would be against the sense itself of virtual memory: the user (third part dev, for example) doesn't put attention about what kind of memory is using, he olny know that it's always available. Virtual Memory has to be trasparent feature from POV of user (he don't know about it, but use it). Sure on AmigaOS it would be good if workbench title bar shows us if we are using VM and how much, but olny as kind of readable user information. Virtual Memory is a low level feature which is ignored by dev POV and have to remain in this way... If you move T: for example in a always VM volume from POV of dev you just change your code to work with real memory, and this is bad because you make assumpion about internal tecnical system parts which are avoidable instead.

@ShInKurO

Quote:

Quote: IMHO, is the ideal solution is the second I proposed in my previous post: having a proper RAM disk, like the one we have had until VM arrived, and a temporary disk (or whatever it will be called), like the current RAM disk. That way, users can still use a 100% authentic RAM disk and, at the same time, have a swappable RAM-based disk for T: and other uses. It's senseless, because it would be against the sense itself of virtual memory: the user (third part dev, for example) doesn't put attention about what kind of memory is using, he olny know that it's always available.

In this post I already listed the first reasons that came to mind why a user could want to use exclusively RAM or, said in a different but equivalent (given the technologies we have now) way, to avoid usage of the HD. Saying in absolute that a user does not care about the kind of memory is false. There are cases when one does care.

Quote:

Virtual Memory has to be trasparent feature from POV of user (he don't know about it, but use it). Sure on AmigaOS it would be good if workbench title bar shows us if we are using VM and how much, but olny as kind of readable user information. Virtual Memory is a low level feature which is ignored by dev POV and have to remain in this way... If you move T: for example in a always VM volume from POV of dev you just change your code to work with real memory, and this is bad because you make assumpion about internal tecnical system parts which are avoidable instead.

It seems you have entirely misunderstood me. This is not what I'm talking about. I'm not talking about developers, I'm not talking about an "always VM volume" (which would be just silly). I'm only saying that users should be given the possibility of choosing to use exclusively the RAM when using the RAM disk.

saimo

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Quote:

I'm only saying that users should be given the possibility of choosing to use exclusively the RAM when using the RAM disk.

You can't:)
Ram Disk is used by many programs to achieve their temporary informations, because it is assumed that it is "memory", it would be like if you could choose between a ram disk done with Chip Ram or Fast Ram, it's not possible. The system has never given you this user level of control. Sure you can tell to OS4Devs to implement other two volumes "PhisicalRamDisk" and "VirtualRamDisk", but you have to mantain Ram Disk as it is because programs and API make many assumption on it which would became wrong and the system would be useless...

@ShInKurO

Quote:

Quote: I'm only saying that users should be given the possibility of choosing to use exclusively the RAM when using the RAM disk. You can't:)

That's why I'm asking to be given the possibility

Quote:

Ram Disk is used by many programs to achieve their temporary informations, because it is assumed that it is "memory", it would be like if you could choose between a ram disk done with Chip Ram or Fast Ram, it's not possible. The system has never given you this user level of control. Sure you can tell to OS4Devs to implement other two volumes "PhisicalRamDisk" and "VirtualRamDisk", but you have to mantain Ram Disk as it is because programs and API make many assumption on it which would became wrong and the system would be useless...

The backwards compatibility argument indeed works in favour of my proposed solution: since RAM disk until now has never been swappable and the change has happened only now as a side effect of the introduction of VM, to ensure 100% compatibility RAM disk should stay unswappable. But honestly I do not think this is much of a issue.

Quote:

Sure you can tell to OS4Devs to implement other two volumes "PhisicalRamDisk" and "VirtualRamDisk"

I'm not asking for that.
I'm asking for keeping the RAM disk as it used to be and adding another device that works as the RAM disk in 4.1 - just to make it crystal clear:
- RAM disk: disk device that resides exclusively in physical memory (as it has always used to be prior to 4.1);
- temporary disk*: a disk device based on physical memory that can be swapped**.

* Or any better name that can be given to it.
** Note that by characterizing this device exclusively as a fast device for temporary usage (i.e. exposing it to the users in an abstract, functional way), future changes in its implementation will not affect user habits and requirements.

saimo

Last edited by saimo on 19-Sep-2008 at 01:37 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Quote:

I'm not asking for that. I'm asking for keeping the RAM disk as it used to be and adding another device that works as the RAM disk in 4.1 - just to make it crystal clear: - RAM disk: disk device that resides exclusively in physical memory (as it has always used to be prior to 4.1); - temporary disk*: a disk device based on physical memory that can be swapped**.

As I believe they have replied you, it not possible because Ram disk rapresents "memory", not "physical" or "virtual", just memory. So program which uses it o any part of it assumes that it is a good and easy way to access to a volatile device, virtual memory has olny extended this behaviour, and it is very useful if there are many temporary files to manage. If you insert that kind of separation, when ram disk will become almost full, AmigaOS should has a trasparent way to move part of files from this ram disk to another one without to assign this work to programmer, it sound like a big hack, and it will not work in any situation. So the olny step, if it was useful (is it?) is to give to user two volumes which have nothing refer with actual Ram Disk...

@ShInKurO

Quote:

As I believe they have replied you, it not possible because Ram disk rapresents "memory", not "physical" or "virtual", just memory.

In Amigaland RAM disk has always meant "drive in physical memory" and nothing else (there must be a reason if icons have that aspect ). Users know it. Developers know it. Applications know it. Things have changed only now with the introduction of the VM. And such a change, as I have pointed out, has its downside.
Moreover, "not possible" does not apply here: not only because the change is very recent (hence neither users, nor programmers, nor applications have suddenly forgotten how to use a "real" RAM disk), but also because the solution I'm suggesting is trivial and works perfectly.

Quote:

So program which uses it o any part of it assumes that it is a good and easy way to access to a volatile device, virtual memory has olny extended this behaviour, and it is very useful if there are many temporary files to manage.

Your reasoning is flawed because it does not consider that the currently existing applications that make use of the RAM disk, along with the assumption that RAM disk "is a good and easy way to access to a volatile device" also *do* know that the RAM disk uses a precious and very limited resource, so they use it properly (in fact, I cannot remeber anybody ever complaining about any applications eating memory by misusing the RAM disk and indeed I cannot remember a single application that would recklessly stuff my RAM with its files): keeping the RAM disk the way it has always been does not cause any problems to current applications *and*, as said in the previous post, is indeed the only way to preserve perfect compatibility (which you seem so concerned about).

Side note: I hope that the availability of a swappable RAM-based device will not give birth to wrong programming practices or unconsidered uses.

Quote:

If you insert that kind of separation, when ram disk will become almost full, AmigaOS should has a trasparent way to move part of files from this ram disk to another one without to assign this work to programmer,

I never said programmers should take the burden of swapping. I was not even talking about programmers.

Quote:

it sound like a big hack

Keeping the RAM disk as it has always been and adding a new device would not be a hack, but instead a very clean solution.

Quote:

and it will not work in any situation.

With those two devices, not only things will keep working exactly like before (because RAM disk behaviour has not changed), but there is the possibility of improving the OS behaviour and the user experience (because of the added flexibility).

Quote:

So the olny step, if it was useful (is it?) is to give to user two volumes which have nothing refer with actual Ram Disk...

The RAM disk in my solution *is* the actual RAM disk.

I think you still do not have a clear picture of what I'm suggesting. I'll try again.
Let's assume we have two devices, RAM: and TMP:* (the former being the classic RAM disk, the second the swappable RAM disk):
- RAM: could be used by who actually wants the data to reside in physical memory;
- TMP: could be used by T:*, CLIPS:, applications/users that make heavy usage of work files without cleanup (which, anyway, is not a good practice IMHO, because also with VM it ends up with overloading the system) and similar.
This way, everybody is happy.

* Actually, I would go for "T:" instead of "TMP:" (so, removing the T: assign in the startup sequence), but I used "TMP:" in the example for clarity.

saimo

Edit: a couple of minor fixes

Last edited by saimo on 19-Sep-2008 at 04:53 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC