lkml.org 
[lkml]   [2000]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: the new VM

On Mon, 25 Sep 2000, Andrea Arcangeli wrote:

> At least Linus's point is that doing perfect accounting (at least on
> the userspace allocation side) may cause you to waste resources,
> failing even if you could still run and I tend to agree with him.
> We're lazy on that side and that's global win in most cases.

well, as i said, i agree that being lazy on the user-space side (which is
by far the biggest RAM allocator in a typical system) makes sense - and we
can handle it cleanly.

Being lazy on the kernel-space side is the default behavior for us kernel
hackers :-) but i dont think it's the right thing in the long term.

> We are finegrined with page granularity, not with the mmap
> granularity. The point is that not all the mmapped regions are going
> to be pagedin. Think a program that only after 1 hour did all the
> calculations that allocated all the memory it requested with malloc.
> Before the hour passes the unused memory can still be used for other
> things and that's what the user also expects when he runs `free`.

i think you've completely missed the fact that i made exactly this point
in my previous mail.

'user-space laziness': correct
'kernel-space laziness': dangerous

i talked about GFP_KERNEL, not GFP_USER. Even in the case of GFP_USER i
believe the right place to oom is via a signal, not in the gfp() case.
(because oom situation in the gfp() case is a completely random and
statistical event, which might have no connection at all to the behavior
of that given process.)

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.188 / U:5.308 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site