OpenVZ Forum - RDF feed
type: channel
items: Re: Re: Linux-VServer example results for sharing vs. separate mappings ...

Re: Re: Linux-VServer example results for sharing vs. separate mappings ...
type: item
description: Andrew Morton wrote: [...skip....] > The problem is memory reclaim. A number of schemes which have been > proposed require a per-container page reclaim mechanism - basically a > separate scanner. > > This is a huge, huge, huge problem. The present scanner has been under > development for over a decade and has had tremendous amounts of work and > testing put into it. And it still has problems. But those problems will > be gradually addressed. > > A per-container recaim scheme really really really wants to reuse all that > stuff rather than creating a separate, parallel, new scanner which has the > same robustness requirements, only has a decade less test and development > done on it. And which permanently doubles our maintenance costs. So if we merge the global/container scanner code, "virtualizing" it and using abstract lists, it will be ok for you? > So how do we reuse our existing scanner? With physical containers. One > can envisage several schemes: > > a) slice the machine into 128 fake NUMA nodes, use each node as the > basic block of memory allocation, manage the binding between these > memory hunks and process groups with cpusets. > > This is what google are testing, and it works. > > b) Create a new memory abstraction, call it the "software zone", which > is mostly decoupled from the present "hardware zones". Most of the MM > is reworked to use "software zones". The "software zones" are > runtime-resizeable, and obtain their pages via some means from the > hardware zones. A container uses a software zone. > > c) Something else, similar to the above. Various schemes can be > envisaged, it isn't terribly important for this discussion. > > > Let me repeat: this all has a huge upside in that it reuses the existing > page reclaimation logic. And cpusets. Yes, we do discover glitches, but > those glitches (such as Christoph's recent discovery of suboptimal > interaction between cpusets and the global dirty ratio) get addressed, and > we tend to strengthen the over…
creator: dev
date: 2007-03-26T09:14:02-00:00