Messages in this thread | | | Date | Tue, 28 Mar 2000 13:45:19 +0200 (CEST) | From | Marco Colombo <> | Subject | Re: Avoiding OOM on overcommit...? |
| |
On Mon, 27 Mar 2000, Linda Walsh wrote:
> Marco Colombo wrote: > > > Does the kernel actually allocate all of these and just "not use > > > them" -- i.e. are these really cases of where space is allocated and then goes > > > unused? I'd think all of these are cases where the kernel was expecting to > > > > Yes. Everytime you malloc() something, use it, and no one else reclaims > > that RAM. Swap space is not used. Why allocate it at malloc() time? > > Just allocate it when neeed. > --- > "malloc"? You were talking kmalloc and the kernel reserving space > for its *internal* data structures. Does the kernel mark address space > withing itself (kernel space) as 'available' but not actually claim a > physical page to map it to? I really really hope not.
Sorry. The whole thread is about what the kernel does when a process performs a malloc() (brk() or mmap()). I didn't realize you were talking of *kernel* allocation. AFAIK, but haven't checked the Source recently, you can't page-fault in kernel mode. So every kernel page is valid (mapped to a page-frame).
> > > But we already do bookkeeping for 'free' > > > memory, 'used' memory, 'shared' memory -- would adding 'committed' or 'reserved' > > > memory really be that much more difficult or costly? > > > > 'reserved' memory? You mean mlock()ed one? Of course it does bookkeeping > > of it. > --- > Reserved meaning removed from the 'free' pool -- that there is > a guaranteed space in the physical mem/swap pool (whther or not the mapping > has actually taken place).
Some kernel allocations should succeed even if we're at the low watermark. That space (page-frames) is "reserved" for kernel use. I don't think the kernel is interested in using the swap for its own address space. B-) So no need to reserve some for kernel use.
> > -l > > -- > Linda A Walsh | Trust Technology, Core Linux, SGI > law@sgi.com | Voice: (650) 933-5338 >
.TM. -- ____/ ____/ / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _____/ _____/ _/ Colombo@ESI.it
- 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/
| |