Re: [ckrm-tech] [RFC][PATCH 5/7] UBC: kernel memory accounting (core) [message #5340] |
Thu, 17 August 2006 17:36 |
Rohit Seth
Messages: 101 Registered: August 2006
|
Senior Member |
|
|
On Thu, 2006-08-17 at 10:23 -0700, Dave Hansen wrote:
> On Thu, 2006-08-17 at 10:16 -0700, Rohit Seth wrote:
> > > That said, it sure is simpler to implement, so I'm all for it!
> >
> > hmm, not sure why it is simpler.
>
> When you ask the question, "which container owns this page?", you don't
> have to look far,
as in page->mapping->container for user land?
> nor is it ambiguous in any way. It is very strict,
> and very straightforward.
What additional ambiguity you have when inode or task structures have
the required information.
-rohit
|
|
|
|
Re: [ckrm-tech] [RFC][PATCH 5/7] UBC: kernel memory accounting (core) [message #5368 is a reply to message #5340] |
Fri, 18 August 2006 08:52 |
dev
Messages: 1693 Registered: September 2005 Location: Moscow
|
Senior Member |
|
|
Rohit Seth wrote:
> On Thu, 2006-08-17 at 10:23 -0700, Dave Hansen wrote:
>
>>On Thu, 2006-08-17 at 10:16 -0700, Rohit Seth wrote:
>>
>>>>That said, it sure is simpler to implement, so I'm all for it!
>>>
>>>hmm, not sure why it is simpler.
>>
>>When you ask the question, "which container owns this page?", you don't
>>have to look far,
>
>
> as in page->mapping->container for user land?
in case of anon_vma, page->mapping can be the same
for 2 pages beloning to different containers.
>>nor is it ambiguous in any way. It is very strict,
>>and very straightforward.
>
> What additional ambiguity you have when inode or task structures have
> the required information.
inodes can belong to multiple containers and so do the pages.
Kirill
|
|
|
|
Re: [ckrm-tech] [RFC][PATCH 5/7] UBC: kernel memory accounting (core) [message #5414 is a reply to message #5368] |
Fri, 18 August 2006 17:38 |
Rohit Seth
Messages: 101 Registered: August 2006
|
Senior Member |
|
|
On Fri, 2006-08-18 at 12:54 +0400, Kirill Korotaev wrote:
> Rohit Seth wrote:
> > On Thu, 2006-08-17 at 10:23 -0700, Dave Hansen wrote:
> >
> >>On Thu, 2006-08-17 at 10:16 -0700, Rohit Seth wrote:
> >>
> >>>>That said, it sure is simpler to implement, so I'm all for it!
> >>>
> >>>hmm, not sure why it is simpler.
> >>
> >>When you ask the question, "which container owns this page?", you don't
> >>have to look far,
> >
> >
> > as in page->mapping->container for user land?
> in case of anon_vma, page->mapping can be the same
> for 2 pages beloning to different containers.
>
In your experience, have you seen processes belonging to different
containers sharing the same anon_vma? On a more general note, could you
please point me to a place that has the list of requirements for which
we are designing this solution.
> >>nor is it ambiguous in any way. It is very strict,
> >>and very straightforward.
> >
> > What additional ambiguity you have when inode or task structures have
> > the required information.
> inodes can belong to multiple containers and so do the pages.
>
I'm still thinking that inodes should belong to one container (or may be
have it configurable based on some flag).
-rohit
|
|
|
|
|
Re: [ckrm-tech] [RFC][PATCH 5/7] UBC: kernel memory accounting (core) [message #5509 is a reply to message #5503] |
Tue, 22 August 2006 07:43 |
xemul
Messages: 248 Registered: November 2005
|
Senior Member |
|
|
Rohit Seth wrote:
[snip]
>>>> inodes can belong to multiple containers and so do the pages.
>>>>
>>>
>>> I'm still thinking that inodes should belong to one container (or may be
>>> have it configurable based on some flag).
>> this is not true for OpenVZ nor Linux-VServer.
>
>
> Well, it is still useful. Just like an anonymous page get charged to
> container where the object (task) belong to, file page seems appropriate
> to belong to container where the object (inode) belongs to.
>
> -rohit
Making inodes belong to one container only significantly shrinks
container density. Sharing of glibc only saves up to 4Mb per container.
For the case of 100 containers it is 400Mb of booth - the disk space
and (what is more important) - RAM.
Pavel.
|
|
|