Nick Piggin wrote:
Eric W. Biederman wrote:
First touch page ownership does not guarantee give me anything useful
for knowing if I can run my application or not. Because of page
sharing my application might run inside the rss limit only because
I got lucky and happened to share a lot of pages
Nick Piggin wrote:
Eric W. Biederman wrote:
First touch page ownership does not guarantee give me anything useful
for knowing if I can run my application or not. Because of page
sharing my application might run inside the rss limit only because
I got lucky and happened to share a lot of pages
Nick Piggin wrote:
Kirill Korotaev wrote:
The approaches I have seen that don't have a struct page pointer, do
intrusive things like try to put hooks everywhere throughout the kernel
where a userspace task can cause an allocation (and of course end up
missing many, so they aren't secure
Kirill Korotaev wrote:
The approaches I have seen that don't have a struct page pointer, do
intrusive things like try to put hooks everywhere throughout the kernel
where a userspace task can cause an allocation (and of course end up
missing many, so they aren't secure anyway)... and basically
Nick,
>>Accounting becomes easy if we have a container pointer in struct page.
>> This can form base ground for building controllers since any memory
>>related controller would be interested in tracking pages. However we
>>still want to evaluate if we can build them without bloating the
>>struct
Cedric Le Goater wrote:
>> --- linux-2.6.20.orig/mm/migrate.c 2007-02-04 21:44:54.0 +0300
>> +++ linux-2.6.20-0/mm/migrate.c 2007-03-06 13:33:28.0 +0300
>> @@ -134,6 +134,7 @@ static void remove_migration_pte(struct
>> pte_t *ptep, pte;
>> spinlock_t *ptl;
>>
> --- linux-2.6.20.orig/mm/migrate.c2007-02-04 21:44:54.0 +0300
> +++ linux-2.6.20-0/mm/migrate.c 2007-03-06 13:33:28.0 +0300
> @@ -134,6 +134,7 @@ static void remove_migration_pte(struct
> pte_t *ptep, pte;
> spinlock_t *ptl;
> unsigned long addr =
Nick Piggin wrote:
> Vaidyanathan Srinivasan wrote:
>
>> Accounting becomes easy if we have a container pointer in struct page.
>> This can form base ground for building controllers since any memory
>> related controller would be interested in tracking pages. However we
>> still want to
Vaidyanathan Srinivasan wrote:
Accounting becomes easy if we have a container pointer in struct page.
This can form base ground for building controllers since any memory
related controller would be interested in tracking pages. However we
still want to evaluate if we can build them without
Balbir Singh wrote:
> Nick Piggin wrote:
>> Balbir Singh wrote:
>>> Nick Piggin wrote:
And strangely, this example does not go outside the parameters of
what you asked for AFAIKS. In the worst case of one container getting
_all_ the shared pages, they will still remain inside
Nick Piggin wrote:
Balbir Singh wrote:
Nick Piggin wrote:
And strangely, this example does not go outside the parameters of
what you asked for AFAIKS. In the worst case of one container getting
_all_ the shared pages, they will still remain inside their maximum
rss limit.
When that does
Nick Piggin wrote:
Balbir Singh wrote:
Nick Piggin wrote:
And strangely, this example does not go outside the parameters of
what you asked for AFAIKS. In the worst case of one container getting
_all_ the shared pages, they will still remain inside their maximum
rss limit.
When that does
Balbir Singh wrote:
Nick Piggin wrote:
Balbir Singh wrote:
Nick Piggin wrote:
And strangely, this example does not go outside the parameters of
what you asked for AFAIKS. In the worst case of one container getting
_all_ the shared pages, they will still remain inside their maximum
rss
Vaidyanathan Srinivasan wrote:
Accounting becomes easy if we have a container pointer in struct page.
This can form base ground for building controllers since any memory
related controller would be interested in tracking pages. However we
still want to evaluate if we can build them without
Nick Piggin wrote:
Vaidyanathan Srinivasan wrote:
Accounting becomes easy if we have a container pointer in struct page.
This can form base ground for building controllers since any memory
related controller would be interested in tracking pages. However we
still want to evaluate if we
Nick,
Accounting becomes easy if we have a container pointer in struct page.
This can form base ground for building controllers since any memory
related controller would be interested in tracking pages. However we
still want to evaluate if we can build them without bloating the
struct page.
--- linux-2.6.20.orig/mm/migrate.c2007-02-04 21:44:54.0 +0300
+++ linux-2.6.20-0/mm/migrate.c 2007-03-06 13:33:28.0 +0300
@@ -134,6 +134,7 @@ static void remove_migration_pte(struct
pte_t *ptep, pte;
spinlock_t *ptl;
unsigned long addr =
Cedric Le Goater wrote:
--- linux-2.6.20.orig/mm/migrate.c 2007-02-04 21:44:54.0 +0300
+++ linux-2.6.20-0/mm/migrate.c 2007-03-06 13:33:28.0 +0300
@@ -134,6 +134,7 @@ static void remove_migration_pte(struct
pte_t *ptep, pte;
spinlock_t *ptl;
unsigned
Kirill Korotaev wrote:
The approaches I have seen that don't have a struct page pointer, do
intrusive things like try to put hooks everywhere throughout the kernel
where a userspace task can cause an allocation (and of course end up
missing many, so they aren't secure anyway)... and basically
Nick Piggin wrote:
Kirill Korotaev wrote:
The approaches I have seen that don't have a struct page pointer, do
intrusive things like try to put hooks everywhere throughout the kernel
where a userspace task can cause an allocation (and of course end up
missing many, so they aren't secure
Balbir Singh wrote:
Nick Piggin wrote:
And strangely, this example does not go outside the parameters of
what you asked for AFAIKS. In the worst case of one container getting
_all_ the shared pages, they will still remain inside their maximum
rss limit.
When that does happen and if a
Nick Piggin wrote:
Eric W. Biederman wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
Eric W. Biederman wrote:
First touch page ownership does not guarantee give me anything useful
for knowing if I can run my application or not. Because of page
sharing my application might run inside the
Eric W. Biederman wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
Eric W. Biederman wrote:
First touch page ownership does not guarantee give me anything useful
for knowing if I can run my application or not. Because of page
sharing my application might run inside the rss limit only because
Nick Piggin <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>> First touch page ownership does not guarantee give me anything useful
>> for knowing if I can run my application or not. Because of page
>> sharing my application might run inside the rss limit only because
>> I got lucky
Eric W. Biederman wrote:
Herbert Poetzl <[EMAIL PROTECTED]> writes:
On Mon, Mar 12, 2007 at 09:50:08AM -0700, Dave Hansen wrote:
On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
For these you essentially need per-container page->_mapcount counter,
otherwise you can't detect
Herbert Poetzl <[EMAIL PROTECTED]> writes:
> On Mon, Mar 12, 2007 at 09:50:08AM -0700, Dave Hansen wrote:
>> On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
>> >
>> > For these you essentially need per-container page->_mapcount counter,
>> > otherwise you can't detect whether rss group
Dave Hansen <[EMAIL PROTECTED]> writes:
> On Mon, 2007-03-12 at 20:07 +0300, Kirill Korotaev wrote:
>> > On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
>> >>For these you essentially need per-container page->_mapcount counter,
>> >>otherwise you can't detect whether rss group still has
Dave Hansen [EMAIL PROTECTED] writes:
On Mon, 2007-03-12 at 20:07 +0300, Kirill Korotaev wrote:
On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
For these you essentially need per-container page-_mapcount counter,
otherwise you can't detect whether rss group still has the page in
Herbert Poetzl [EMAIL PROTECTED] writes:
On Mon, Mar 12, 2007 at 09:50:08AM -0700, Dave Hansen wrote:
On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
For these you essentially need per-container page-_mapcount counter,
otherwise you can't detect whether rss group still has the
Eric W. Biederman wrote:
Herbert Poetzl [EMAIL PROTECTED] writes:
On Mon, Mar 12, 2007 at 09:50:08AM -0700, Dave Hansen wrote:
On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
For these you essentially need per-container page-_mapcount counter,
otherwise you can't detect whether
Nick Piggin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
First touch page ownership does not guarantee give me anything useful
for knowing if I can run my application or not. Because of page
sharing my application might run inside the rss limit only because
I got lucky and happened
Eric W. Biederman wrote:
Nick Piggin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
First touch page ownership does not guarantee give me anything useful
for knowing if I can run my application or not. Because of page
sharing my application might run inside the rss limit only because
I
Nick Piggin wrote:
Eric W. Biederman wrote:
Nick Piggin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
First touch page ownership does not guarantee give me anything useful
for knowing if I can run my application or not. Because of page
sharing my application might run inside the rss
Balbir Singh wrote:
Nick Piggin wrote:
And strangely, this example does not go outside the parameters of
what you asked for AFAIKS. In the worst case of one container getting
_all_ the shared pages, they will still remain inside their maximum
rss limit.
When that does happen and if a
On Mon, Mar 12, 2007 at 09:50:08AM -0700, Dave Hansen wrote:
> On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
> >
> > For these you essentially need per-container page->_mapcount counter,
> > otherwise you can't detect whether rss group still has the page
> > in question being mapped
On Mon, 2007-03-12 at 20:07 +0300, Kirill Korotaev wrote:
> > On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
> >>For these you essentially need per-container page->_mapcount counter,
> >>otherwise you can't detect whether rss group still has the page in question
> >>being mapped
> >>in
> On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
>
>>For these you essentially need per-container page->_mapcount counter,
>>otherwise you can't detect whether rss group still has the page in question
>>being mapped
>>in its processes' address spaces or not.
>
>
> What do you mean
On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
>
> For these you essentially need per-container page->_mapcount counter,
> otherwise you can't detect whether rss group still has the page in question
> being mapped
> in its processes' address spaces or not.
What do you mean by this?
Eric W. Biederman wrote:
> Pavel Emelianov <[EMAIL PROTECTED]> writes:
>
>
>>Pages are charged to their first touchers which are
>>determined using pages' mapcount manipulations in
>>rmap calls.
>
>
> NAK pages should be charged to every rss group whose mm_struct they
> are mapped into.
For
Eric W. Biederman wrote:
Pavel Emelianov [EMAIL PROTECTED] writes:
Pages are charged to their first touchers which are
determined using pages' mapcount manipulations in
rmap calls.
NAK pages should be charged to every rss group whose mm_struct they
are mapped into.
For these you
On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
For these you essentially need per-container page-_mapcount counter,
otherwise you can't detect whether rss group still has the page in question
being mapped
in its processes' address spaces or not.
What do you mean by this? You
On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
For these you essentially need per-container page-_mapcount counter,
otherwise you can't detect whether rss group still has the page in question
being mapped
in its processes' address spaces or not.
What do you mean by this? You
On Mon, 2007-03-12 at 20:07 +0300, Kirill Korotaev wrote:
On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
For these you essentially need per-container page-_mapcount counter,
otherwise you can't detect whether rss group still has the page in question
being mapped
in its processes'
On Mon, Mar 12, 2007 at 09:50:08AM -0700, Dave Hansen wrote:
On Mon, 2007-03-12 at 19:23 +0300, Kirill Korotaev wrote:
For these you essentially need per-container page-_mapcount counter,
otherwise you can't detect whether rss group still has the page
in question being mapped in its
Pavel Emelianov <[EMAIL PROTECTED]> writes:
> Pages are charged to their first touchers which are
> determined using pages' mapcount manipulations in
> rmap calls.
NAK pages should be charged to every rss group whose mm_struct they
are mapped into.
Eric
-
To unsubscribe from this list: send the
Pavel Emelianov [EMAIL PROTECTED] writes:
Pages are charged to their first touchers which are
determined using pages' mapcount manipulations in
rmap calls.
NAK pages should be charged to every rss group whose mm_struct they
are mapped into.
Eric
-
To unsubscribe from this list: send the line
46 matches
Mail list logo
