Messages in this thread | | | Date | Sun, 12 Mar 2000 21:57:59 -0500 (EST) | From | Gregory Maxwell <> | Subject | Re: Overcommitable memory?? Re: Some questions about linux kernel. |
| |
On Sun, 12 Mar 2000, Michael Bacarella wrote:
> > > I take it you run your sash mlock()ed with a special > > > kernel patch to make sure procfs doesn't need to allocate > > > memory on sash's behalf :) > > > > Unfortunatelly not. > > > > But if would be posible to somehow dividie the memory into overcommitable > > and one which is not overcommitable it could help. > > Wouldn't this problem be avoided if the kernel DIDN'T overcommit memory?
No. You stil can run out of memory, allocations can fail, apps will still crash. It's just a little more predictiable.
> I mean, nobody tolerates their filesystem overcommitting blocks it > doesn't have (or maybe they do and my reality is a myth). Why should > it be tolerated for virtual memory?
You are living in a fantasy world. [root@firewall /tmp]# df -k . Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda7 257598 2 244292 0% /tmp
dd if=/dev/zero of=hole bs=4096 seek=102400 count=1 1+0 records in 1+0 records out [root@firewall /tmp]# ls -l total 8 -rw------- 1 root root 348 Mar 12 21:46 file -rw-r--r-- 1 root root 419434496 Mar 12 21:56 hole [root@firewall /tmp]# df -k . Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda7 257598 9 244285 0% /tmp
> Are the benefits to saying "uh, sure. we only have 600 megs of VM, but uh, > feel free to let your system commit 1 gig" worth it? What makes that > behavior desirable? > > I'm not condemning, I'm just curious.
Because many times that VM space is going to be used sparsely.
Worse is better.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |