lkml.org 
[lkml]   [2000]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: the new VMt
On Tue, Sep 26, 2000 at 11:07:36AM +0100, Stephen C. Tweedie wrote:
> Hi,
>
> On Mon, Sep 25, 2000 at 03:12:50PM -0600, yodaiken@fsmlabs.com wrote:
> > > >
> > > > I'm not too sure of what you have in mind, but if it is
> > > > "process creates vast virtual space to generate many page table
> > > > entries -- using mmap"
> > > > the answer is, virtual address space quotas and mmap should kill
> > > > the process on low mem for page tables.
> > >
> > > No. Page tables are not freed after munmap (and for good reason). The
> > > counting of page table "beans" is critical.
> >
> > I've seen the assertion before, reasons would be interesting.
>
> Reason 1: under DoS attack, you want to target not the process using
> the most resources, but the *user* using the most resources (else a
> fork-bomb style attack can work around your OOM-killer algorithms).

Ok.
if(over_allocated_page_tables(task->uid) ) return ENOMEM;

makes sense in "fork". I guess the argument here is not about whether
accounting is good, it's about where the accounting should be done. To me
the alternatives of

if(preallocate_pages(page_table_size_for_this_process()) == -1)return error
then actually allocate making sure to adjust counts if some other
error turns up and with something taking care of how the pre-allocation
works while we are sleeping waiting for possibly unrelated resources.

or
just kmalloc with kmalloc magically juggling resources in some safe way


seem less clear.





> Reason 2: if you've got tasks stuck in low-level page allocation
> routines, then you can't immediately kill -9 them, so reactive OOM
> killing always has vulnerabilities --- to be robust in preventing
> resource exhaustion you want limits on the use of those resources
> before they are exhausted --- the necessary accounting being part of
> what we refer to as "beancounter".

doesn't the problem really come from low level page allocation at too high a level?
That is, if instead of select doing get_free_page, it maybe should do
get_per_process_page(myprocess) or even get_per_process_file_use_page(myprocess)
Then we could have a config-optional per-process pinned page accounting with the
possibility of doing something sensible in a user-space daemon when memory is low.

>
> --Stephen

--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com

-
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:39    [W:0.237 / U:0.832 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site