Re: [ckrm-tech] [RFC][PATCH 5/7] UBC: kernel memory accounting (core)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dave Hansen wrote:
On Fri, 2006-08-18 at 13:31 +0400, Kirill Korotaev wrote:

they all are troublesome :/
user can create lots of vmas, w/o page tables.
lots of fdsets, ipcids.
These are not reclaimable.


I guess one of my big questions surrounding these patches is why the
accounting is done with pages.
probably you missed patch details a bit.
accounting is done:
1. in pages for objects allocated by buddy allocator
2. in slabs for objects allocated from caches

If there really is a need to limit these
different kernel objects, then why not simply write patches to limit
*these* *objects*?  I trust there is a very good technical reason for
doing this, I just don't understand why, yet.
The one reason is that such an accounting allows to estimate the memory
used/required by containers, while limitations by objects:
- per object accounting/limitations do not provide any memory estimation
- having a big number of reasonably high limits still allows the user
 to consume big amount of memory. I.e. the sum of all the limits tend
 to be high and potentially DoS exploitable :/
- memory is easier to setup/control from user POV.
 having hundreds of controls is good, but not much user friendly.

Thanks,
Kirill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux