Re: 'disposable' dirty pages [was: Out Of Memory in v. 2.1]

Ely Wilson (plexus@ionet.net)
Thu, 8 Oct 1998 12:16:12 -0500 (CDT)


>
> There is a _reason_ why malloc doesnt return pages immediately. It's
> performance. There is a reason why X caches pixmaps. It's performance. So
> sure we could drop all these features but thats not the point. The point
> is to have good performance when everything is OK, and to still have the
> option of immediately disposing pages when (say accidentally) memory went
> low and the system got into an impossible situation. It's an additional
> mechanizm.

sure.

>
> portability is not an issue, we controll all the platforms and libc too.
> It might be hard to implement it, but thats not the question. The question
> is, how much memory will this free up, and how hard would it be to _use_
> this in applications.
>
Are you suggesting that all previous programs should be modified (even if
over long time) to make use of a new feature such as an OOM notification
system?

And what ever happened to soemone argument about checking/handling NULL
was more work for the programmer? Hmm? Which is more? Implementing a
scheme where your prorgam will attempt to free as much memory as posible
or making sur eyou never use more than you need to begin with.

But maybe this would be something to implement atop the application layer,
something behind thescenes and mostly handeld by the kernel.

Personally, I would like a malloc() that freed my memory when I felt it
should be freed. I woudl also expect my program to actually have access
to the memory that it was told it had access to.

Maybe I'm old and goatish. But that's how I feel.

-
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/