Displaying 19 results from an estimated 19 matches for "__setpageisolated".
2016 Apr 04
0
[PATCH v3 03/16] mm: add non-lru movable page support document
...and transfer data directly between the storage and the
> > application's address space.
> >
> >+ isolate_page: Called by the VM when isolating a movable non-lru page.
> >+ If page is successfully isolated, we should mark the page as
> >+ PG_isolated via __SetPageIsolated.
>
> Patch 02 changelog suggests SetPageIsolated, so this is confusing. I
> guess the main point is that there might be parallel attempts and
> only one is allowed to succeed, right? Whether it's done by atomic
Right.
> ops or otherwise doesn't matter to e.g. compaction....
2016 Apr 01
2
[PATCH v3 03/16] mm: add non-lru movable page support document
...tions {
> and transfer data directly between the storage and the
> application's address space.
>
> + isolate_page: Called by the VM when isolating a movable non-lru page.
> + If page is successfully isolated, we should mark the page as
> + PG_isolated via __SetPageIsolated.
Patch 02 changelog suggests SetPageIsolated, so this is confusing. I guess the
main point is that there might be parallel attempts and only one is allowed to
succeed, right? Whether it's done by atomic ops or otherwise doesn't matter to
e.g. compaction.
> migrate_page: This is...
2016 Apr 01
2
[PATCH v3 03/16] mm: add non-lru movable page support document
...tions {
> and transfer data directly between the storage and the
> application's address space.
>
> + isolate_page: Called by the VM when isolating a movable non-lru page.
> + If page is successfully isolated, we should mark the page as
> + PG_isolated via __SetPageIsolated.
Patch 02 changelog suggests SetPageIsolated, so this is confusing. I guess the
main point is that there might be parallel attempts and only one is allowed to
succeed, right? Whether it's done by atomic ops or otherwise doesn't matter to
e.g. compaction.
> migrate_page: This is...
2016 Mar 30
0
[PATCH v3 03/16] mm: add non-lru movable page support document
...@@ struct address_space_operations {
and transfer data directly between the storage and the
application's address space.
+ isolate_page: Called by the VM when isolating a movable non-lru page.
+ If page is successfully isolated, we should mark the page as
+ PG_isolated via __SetPageIsolated.
+
migrate_page: This is used to compact the physical memory usage.
If the VM wants to relocate a page (maybe off a memory card
that is signalling imminent failure) it will pass a new page
and an old page to this function. migrate_page should
transfer any private data acr...
2016 May 09
0
[PATCH v5 02/12] mm: migrate: support non-lru movable page migration
...752,10 @@ struct address_space_operations {
and transfer data directly between the storage and the
application's address space.
+ isolate_page: Called by the VM when isolating a movable non-lru page.
+ If page is successfully isolated, VM marks the page as PG_isolated
+ via __SetPageIsolated.
+
migrate_page: This is used to compact the physical memory usage.
If the VM wants to relocate a page (maybe off a memory card
that is signalling imminent failure) it will pass a new page
@@ -754,6 +763,8 @@ struct address_space_operations {
transfer any private data across...
2016 May 20
0
[PATCH v6 02/12] mm: migrate: support non-lru movable page migration
...752,10 @@ struct address_space_operations {
and transfer data directly between the storage and the
application's address space.
+ isolate_page: Called by the VM when isolating a movable non-lru page.
+ If page is successfully isolated, VM marks the page as PG_isolated
+ via __SetPageIsolated.
+
migrate_page: This is used to compact the physical memory usage.
If the VM wants to relocate a page (maybe off a memory card
that is signalling imminent failure) it will pass a new page
@@ -754,6 +763,8 @@ struct address_space_operations {
transfer any private data across...
2016 May 31
0
[PATCH v6v3 02/12] mm: migrate: support non-lru movable page migration
...744,10 @@ struct address_space_operations {
and transfer data directly between the storage and the
application's address space.
+ isolate_page: Called by the VM when isolating a movable non-lru page.
+ If page is successfully isolated, VM marks the page as PG_isolated
+ via __SetPageIsolated.
+
migrate_page: This is used to compact the physical memory usage.
If the VM wants to relocate a page (maybe off a memory card
that is signalling imminent failure) it will pass a new page
@@ -746,6 +755,8 @@ struct address_space_operations {
transfer any private data across...
2016 May 30
5
PATCH v6v2 02/12] mm: migrate: support non-lru movable page migration
...744,10 @@ struct address_space_operations {
and transfer data directly between the storage and the
application's address space.
+ isolate_page: Called by the VM when isolating a movable non-lru page.
+ If page is successfully isolated, VM marks the page as PG_isolated
+ via __SetPageIsolated.
+
migrate_page: This is used to compact the physical memory usage.
If the VM wants to relocate a page (maybe off a memory card
that is signalling imminent failure) it will pass a new page
@@ -746,6 +755,8 @@ struct address_space_operations {
transfer any private data across...
2016 May 30
5
PATCH v6v2 02/12] mm: migrate: support non-lru movable page migration
...744,10 @@ struct address_space_operations {
and transfer data directly between the storage and the
application's address space.
+ isolate_page: Called by the VM when isolating a movable non-lru page.
+ If page is successfully isolated, VM marks the page as PG_isolated
+ via __SetPageIsolated.
+
migrate_page: This is used to compact the physical memory usage.
If the VM wants to relocate a page (maybe off a memory card
that is signalling imminent failure) it will pass a new page
@@ -746,6 +755,8 @@ struct address_space_operations {
transfer any private data across...
2016 May 20
5
[PATCH v6 00/12] Support non-lru page migration
Recently, I got many reports about perfermance degradation in embedded
system(Android mobile phone, webOS TV and so on) and easy fork fail.
The problem was fragmentation caused by zram and GPU driver mainly.
With memory pressure, their pages were spread out all of pageblock and
it cannot be migrated with current compaction algorithm which supports
only LRU pages. In the end, compaction cannot
2016 May 20
5
[PATCH v6 00/12] Support non-lru page migration
Recently, I got many reports about perfermance degradation in embedded
system(Android mobile phone, webOS TV and so on) and easy fork fail.
The problem was fragmentation caused by zram and GPU driver mainly.
With memory pressure, their pages were spread out all of pageblock and
it cannot be migrated with current compaction algorithm which supports
only LRU pages. In the end, compaction cannot
2016 May 09
5
[PATCH v5 00/13] Support non-lru page migration
Recently, I got many reports about perfermance degradation in embedded
system(Android mobile phone, webOS TV and so on) and easy fork fail.
The problem was fragmentation caused by zram and GPU driver mainly.
With memory pressure, their pages were spread out all of pageblock and
it cannot be migrated with current compaction algorithm which supports
only LRU pages. In the end, compaction cannot
2016 May 09
5
[PATCH v5 00/13] Support non-lru page migration
Recently, I got many reports about perfermance degradation in embedded
system(Android mobile phone, webOS TV and so on) and easy fork fail.
The problem was fragmentation caused by zram and GPU driver mainly.
With memory pressure, their pages were spread out all of pageblock and
it cannot be migrated with current compaction algorithm which supports
only LRU pages. In the end, compaction cannot
2016 Apr 27
4
[PATCH v4 00/13] Support non-lru page migration
Recently, I got many reports about perfermance degradation in embedded
system(Android mobile phone, webOS TV and so on) and easy fork fail.
The problem was fragmentation caused by zram and GPU driver mainly.
With memory pressure, their pages were spread out all of pageblock and
it cannot be migrated with current compaction algorithm which supports
only LRU pages. In the end, compaction cannot
2016 Apr 27
4
[PATCH v4 00/13] Support non-lru page migration
Recently, I got many reports about perfermance degradation in embedded
system(Android mobile phone, webOS TV and so on) and easy fork fail.
The problem was fragmentation caused by zram and GPU driver mainly.
With memory pressure, their pages were spread out all of pageblock and
it cannot be migrated with current compaction algorithm which supports
only LRU pages. In the end, compaction cannot
2016 May 31
7
[PATCH v7 00/12] Support non-lru page migration
Recently, I got many reports about perfermance degradation in embedded
system(Android mobile phone, webOS TV and so on) and easy fork fail.
The problem was fragmentation caused by zram and GPU driver mainly.
With memory pressure, their pages were spread out all of pageblock and
it cannot be migrated with current compaction algorithm which supports
only LRU pages. In the end, compaction cannot
2016 May 31
7
[PATCH v7 00/12] Support non-lru page migration
Recently, I got many reports about perfermance degradation in embedded
system(Android mobile phone, webOS TV and so on) and easy fork fail.
The problem was fragmentation caused by zram and GPU driver mainly.
With memory pressure, their pages were spread out all of pageblock and
it cannot be migrated with current compaction algorithm which supports
only LRU pages. In the end, compaction cannot
2016 Mar 30
33
[PATCH v3 00/16] Support non-lru page migration
Recently, I got many reports about perfermance degradation
in embedded system(Android mobile phone, webOS TV and so on)
and failed to fork easily.
The problem was fragmentation caused by zram and GPU driver
pages. Their pages cannot be migrated so compaction cannot
work well, either so reclaimer ends up shrinking all of working
set pages. It made system very slow and even to fail to fork
easily.
2016 Mar 30
33
[PATCH v3 00/16] Support non-lru page migration
Recently, I got many reports about perfermance degradation
in embedded system(Android mobile phone, webOS TV and so on)
and failed to fork easily.
The problem was fragmentation caused by zram and GPU driver
pages. Their pages cannot be migrated so compaction cannot
work well, either so reclaimer ends up shrinking all of working
set pages. It made system very slow and even to fail to fork
easily.