| Re: [ckrm-tech] [RFC][PATCH 5/7] UBC: kernel memory accounting (core) [message #5306] |
Thu, 17 August 2006 14:41  |
Alan Cox
Messages: 48
Registered: May 2006
|
Member |
|
|
Ar Iau, 2006-08-17 am 07:26 -0700, ysgrifennodd Dave Hansen:
> My main thought is that _everybody_ is going to have to live with the
> entry in the 'struct page'. Distros ship one kernel for everybody, and
> the cost will be paid by those not even using any kind of resource
> control or containers.
>
> That said, it sure is simpler to implement, so I'm all for it!
I don't see any good way around that. For the page struct it is a
material issue, for the others its not a big deal providing we avoid
accounting dumb stuff like dentries.
At the VM summit Linus suggested one option for user page allocation
tracking would be to track not per page but by block of pages (say the
2MB chunks) and hand those out per container. That would really need the
defrag work though.
|
|
|
|
|
|
| Re: [ckrm-tech] [RFC][PATCH 5/7] UBC: kernel memory accounting (core) [message #5338 is a reply to message #5306] |
Thu, 17 August 2006 16:37  |
Dave Hansen
Messages: 240
Registered: October 2005
|
Senior Member |
|
|
On Thu, 2006-08-17 at 16:01 +0100, Alan Cox wrote:
> Ar Iau, 2006-08-17 am 07:26 -0700, ysgrifennodd Dave Hansen:
> > My main thought is that _everybody_ is going to have to live with the
> > entry in the 'struct page'. Distros ship one kernel for everybody, and
> > the cost will be paid by those not even using any kind of resource
> > control or containers.
> >
> > That said, it sure is simpler to implement, so I'm all for it!
>
> I don't see any good way around that. For the page struct it is a
> material issue, for the others its not a big deal providing we avoid
> accounting dumb stuff like dentries.
The only way I see around it is using other mechanisms to more loosely
attribute ownership of a page to particular containers. I know that my
suggestion of traversing the rmap chains at page reclaim time is going
appears to be slow compared to the regular reclaim path, but I'm not
sure it really matters.
Let's say you have 20 containers sharing 20 pages which are on the LRU,
and those pages are evenly distributed so that each container owns one
page. Only one of those 20 containers is over its limit. With
something that strictly assigns container ownership to one and only one
container, you're going to have to walk half of the LRU to find the
page.
With a "loose ownership" scheme, you'd hit on the first page, and you'd
pay the cost by having to walk halfway through the 20 rmap entries.
Admittedly, the rmap walk is much slower than an LRU walk.
-- Dave
|
|
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
