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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:23 EST