Messages in this thread |  | | Date | Tue, 26 Sep 2000 07:30:15 -0600 | From | yodaiken@fsmlabs ... | Subject | Re: 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/
|  |