Matthew Dillon once wrote:
> :On Irix, each swap area has the following parameter (from swap(1M)):
> :
> : vswap The size the system believes the area can hold. This is
> : always greater than or equal to pswap and maxswap.
> :
> :This way, an administrator can control the amount of overcommited
> :memory (making it 0 if neccessary). It may be sufficient to have this
> :as a centralized parameter, rather then a per swap area.
> I think they finally got rid of vswap in later IRIX's after they
> fixed the core swapping code to 'overcommit'. The reality behind
> the virtual swap concept w/ IRIX is based on issues with the original
[...]
Mmm, that's how they use(d) it then... But can we have a way for an
admin to control the amount of overcommited memory? Ranging from 0 -- no
overcommitment to the entire addressable space less the phisical storage
(the current situation)... And this is different from the per-user class
limit.
I guess, I'd settle for being able to specify the per-user class:
. datasize limit in percents of the total available RAM+swap
. kill-order, so the kernel will start killing with the least
important users (and services running in their own sandboxes)
Does not fix the non-compliance with ANSI, strictly speaking...
> FreeBSD does it right - it only allocates swap when it needs to
> swap something out of main memory. The total available VM is
> essentially the amount of main memory plus the amount of swap
> (non-inclusive of mmap()'d files which do not take any swap at
> all).
FreeBSD is perfect for my existing needs...
> :They also have priorities of the swap areas (only swap here when
> :areas with higher priorities are full), and an ability to stop
> :paging onto a particular area. Mmmm...
What about this two?
-mi
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
