[PATCH v2 13/18] mm/compaction: support non-lru movable pagemigration

2016-03-24 Thread Gioh Kim
An HTML attachment was scrubbed...
URL: 



[PATCH 0/4] enable migration of driver pages

2015-07-30 Thread Gioh Kim


2015-07-29 오후 9:46에 Daniel Vetter 이(가) 쓴 글:
> On Wed, Jul 29, 2015 at 01:16:14PM +0100, Mel Gorman wrote:
>> On Wed, Jul 29, 2015 at 12:55:54PM +0200, Daniel Vetter wrote:
>>> On Wed, Jul 29, 2015 at 11:49:45AM +0100, Mel Gorman wrote:
>>>> On Mon, Jul 13, 2015 at 05:35:15PM +0900, Gioh Kim wrote:
>>>>> My ARM-based platform occured severe fragmentation problem after long-term
>>>>> (several days) test. Sometimes even order-3 page allocation failed. It has
>>>>> memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic 
>>>>> processing
>>>>> and 20~30 memory is reserved for zram.
>>>>>
>>>>
>>>> The primary motivation of this series is to reduce fragmentation by 
>>>> allowing
>>>> more kernel pages to be moved. Conceptually that is a worthwhile goal but
>>>> there should be at least one major in-kernel user and while balloon
>>>> pages were a good starting point, I think we really need to see what the
>>>> zram changes look like at the same time.
>>>
>>> I think gpu drivers really would be the perfect candidate for compacting
>>> kernel page allocations. And this also seems the primary motivation for
>>> this patch series, so I think that's really what we should use to judge
>>> these patches.
>>>
>>> Of course then there's the seemingly eternal chicken/egg problem of
>>> upstream gpu drivers for SoCs :(
>>
>> I recognised that the driver he had modified was not an in-tree user so
>> it did not really help the review or the design. I did not think it was
>> very fair to ask that an in-tree GPU driver be converted when it would not
>> help the embedded platform of interest. Converting zram is both a useful
>> illustration of the aops requirements and is expected to be beneficial on
>> the embedded platform. Now, if a GPU driver author was willing to convert
>> theirs as an example then that would be useful!
>
> Well my concern is more with merging infrastructure to upstream for
> drivers which aren't upstream and with no plan to make that happen anytime
> soon. Seems like just offload a bit to me ... but in the end core mm isn't
> my thing so not my decision.
> -Daniel
>

I get idea from the out-tree driver but this infrastructure will be useful
for zram and balloon. That is agreed by the maintainers of each driver.

I'm currently accepting feedbacks from
balloon and zram and trying to be applicable for them.
Of course I hope there will be more application. It'll be more useful
if it has more application.


[PATCH 4/4] mm: remove direct calling of migration

2015-07-28 Thread Gioh Kim


2015-07-27 오후 10:58에 Vlastimil Babka 이(가) 쓴 글:
> On 07/13/2015 10:35 AM, Gioh Kim wrote:
>> From: Gioh Kim 
>>
>> Migration is completely generalized so that migrating mobile page
>> is processed with lru-pages in move_to_new_page.
>>
>> Signed-off-by: Gioh Kim 
>> Acked-by: Rafael Aquini 
>
> Why not just fold this to Patch 3? You already modify this hunk there, and 
> prior to patch 3, the hunk was balloon-pages specific. You made it look 
> generic only to remove it, which is unneeded code churn and I don't think it 
> adds anything wrt e.g. bisectability.
Yes, you have a point.
I'll be merged into 3/4 at next spin.

I wanted to show the process how migration is generalized with this patch.
On second thought it is not necessary.

>
>> ---
>>   mm/migrate.c | 15 ---
>>   1 file changed, 15 deletions(-)
>>
>> diff --git a/mm/migrate.c b/mm/migrate.c
>> index 53f0081d..e6644ac 100644
>> --- a/mm/migrate.c
>> +++ b/mm/migrate.c
>> @@ -844,21 +844,6 @@ static int __unmap_and_move(struct page *page, struct 
>> page *newpage,
>>   }
>>   }
>>
>> -if (unlikely(mobile_page(page))) {
>> -/*
>> - * A mobile page does not need any special attention from
>> - * physical to virtual reverse mapping procedures.
>> - * Skip any attempt to unmap PTEs or to remap swap cache,
>> - * in order to avoid burning cycles at rmap level, and perform
>> - * the page migration right away (proteced by page lock).
>> - */
>> -lock_page(newpage);
>> -rc = page->mapping->a_ops->migratepage(page->mapping,
>> -   newpage, page, mode);
>> -unlock_page(newpage);
>> -goto out_unlock;
>> -}
>> -
>>   /*
>>* Corner case handling:
>>* 1. When a new swap-cache page is read into, it is added to the LRU
>>
>
>


[PATCH 2/4] mm/compaction: enable mobile-page migration

2015-07-28 Thread Gioh Kim



> On Mon, Jul 27, 2015 at 4:55 PM, Vlastimil Babka  wrote:
>> On 07/13/2015 10:35 AM, Gioh Kim wrote:
>>>
>>> From: Gioh Kim 
>>>
>>> Add framework to register callback functions and check page mobility.
>>> There are some modes for page isolation so that isolate interface
>>> has arguments of page address and isolation mode while putback
>>> interface has only page address as argument.
>>
>>
>> Note that unlike what subject suggest, this doesn't really enable
>> mobile-page migration inside compaction, since that only happens with patch
>> 3. This might theoretically affect some cherry-pick backports that don't
>> care about balloon pages. I can imagine that can easily happen in the world
>> of mobile devices?
>> It would thus be somewhat cleaner if this patch was complete in that sense.

You have a point.
Current 2/4 patch is lack of calling migrate/isolate.
It is not complete without 3/4.

I'll add calling migrate/isolate() at next spin.


>>
>>> Signed-off-by: Gioh Kim 
>>> Acked-by: Rafael Aquini 
>>> ---
>>>fs/proc/page.c |  3 ++
>>>include/linux/compaction.h | 80
>>> ++
>>>include/linux/fs.h |  2 +
>>>include/linux/page-flags.h | 19 
>>>include/uapi/linux/kernel-page-flags.h |  1 +
>>>5 files changed, 105 insertions(+)
>>>
>>> diff --git a/fs/proc/page.c b/fs/proc/page.c
>>> index 7eee2d8..a4f5a00 100644
>>> --- a/fs/proc/page.c
>>> +++ b/fs/proc/page.c
>>> @@ -146,6 +146,9 @@ u64 stable_page_flags(struct page *page)
>>>  if (PageBalloon(page))
>>>  u |= 1 << KPF_BALLOON;
>>>
>>> +   if (PageMobile(page))
>>> +   u |= 1 << KPF_MOBILE;
>>
>>
>> PageMovable() would probably be as good a name and correspond to
>> MIGRATE_MOVABLE somewhat, unlike a completely new term. Whatever driver
>> starts to using this should probably change allocation flags to allocate
>> MIGRATE_MOVABLE, so that it works fine with what fragmentation avoidance
>> expects. Guess I should have said that earlier, but can you still
>> reconsider?
>
> Well, I've suggested to name it "mobile" because there's already a lot of 
> things
> called "movable". Mobile pages are special subset of movable pages: they
> are non-lru pages and define their own rules of moving in address
> space operations.
>
> Also there's a little pun: I guess main user will zram which is used
> mostly in embedded/mobile devices.

I like "mobile".
"movable" is for pages allocated with GFP_MOVABLE.
I think "movable" is a little ambiguous in this situation.

>
>>
>>> +
>>>  u |= kpf_copy_bit(k, KPF_LOCKED,PG_locked);
>>>
>>>  u |= kpf_copy_bit(k, KPF_SLAB,  PG_slab);
>>> diff --git a/include/linux/compaction.h b/include/linux/compaction.h
>>> index aa8f61c..f693072 100644
>>> --- a/include/linux/compaction.h
>>> +++ b/include/linux/compaction.h
>>> @@ -1,6 +1,9 @@
>>>#ifndef _LINUX_COMPACTION_H
>>>#define _LINUX_COMPACTION_H
>>>
>>> +#include 
>>> +#include 
>>> +
>>>/* Return values for compact_zone() and try_to_compact_pages() */
>>>/* compaction didn't start as it was deferred due to past failures */
>>>#define COMPACT_DEFERRED  0
>>> @@ -51,6 +54,70 @@ extern void compaction_defer_reset(struct zone *zone,
>>> int order,
>>>  bool alloc_success);
>>>extern bool compaction_restarting(struct zone *zone, int order);
>>>
>>> +static inline bool mobile_page(struct page *page)
>>> +{
>>> +   return page->mapping && (PageMobile(page) || PageBalloon(page));
>>> +}
>>
>>
>> I would put this definition to linux/page-flags.h and rename it to
>> page_mobile (or better page_movable()), which is more common ordering.
>>
>>> +
>>> +static inline bool isolate_mobilepage(struct page *page, isolate_mode_t
>>> mode)
>>
>>
>> Does this have to be in compaction.h? The only user is compaction.c so
>> probably move it there, and if there ever is another module using this in
>> the future, we can move it to a more appropriate place and declare it in
>> e.g. mm/internal.h.

I think compaction.c is suitable.

>>
>&

[PATCH 0/4] enable migration of driver pages

2015-07-13 Thread Gioh Kim


2015-07-13 오후 6:24에 Konstantin Khlebnikov 이(가) 쓴 글:
> On Mon, Jul 13, 2015 at 11:35 AM, Gioh Kim  wrote:
>> From: Gioh Kim 
>>
>> Hello,
>>
>> This series try to enable migration of non-LRU pages, such as driver's page.
>>
>> My ARM-based platform occured severe fragmentation problem after long-term
>> (several days) test. Sometimes even order-3 page allocation failed. It has
>> memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic 
>> processing
>> and 20~30 memory is reserved for zram.
>>
>> I found that many pages of GPU driver and zram are non-movable pages. So I
>> reported Minchan Kim, the maintainer of zram, and he made the internal
>> compaction logic of zram. And I made the internal compaction of GPU driver.
>>
>> They reduced some fragmentation but they are not enough effective.
>> They are activated by its own interface, /sys, so they are not cooperative
>> with kernel compaction. If there is too much fragmentation and kernel starts
>> to compaction, zram and GPU driver cannot work with the kernel compaction.
>>
>> So I thought there needs a interface to combine driver and kernel compaction.
>> This patch adds a generic isolate/migrate/putback callbacks for page
>> address-space and a new interface to create anon-inode to manage
>> address_space_operation. The zram and GPU, and any other modules can create
>> anon_inode and register its own migration method. The kernel compaction can
>> call the registered migration when it does compaction.
>>
>> My GPU driver source is not in-kernel driver so that I apply the interface
>> into balloon driver. The balloon driver is already merged
>> into the kernel compaction as a corner-case. This patch have the balloon
>> driver migration be called by the generic interface.
>>
>>
>> This patch set combines 4 patches.
>>
>> 1. patch 1/4: get inode from anon_inodes
>> This patch adds new interface to create inode from anon_inodes.
>>
>> 2. patch 2/4: framework to isolate/migrate/putback page
>> Add isolatepage, putbackpage into address_space_operations
>> and wrapper function to call them.
>>
>> 3. patch 3/4: apply the framework into balloon driver
>> The balloon driver is applied into the framework. It gets a inode
>> from anon_inodes and register operations in the inode.
>> The kernel compaction calls generic interfaces, not balloon
>> driver interfaces.
>> Any other drivers can register operations via inode like this
>> to migrate it's pages.
>>
>> 4. patch 4/4: remove direct calling of migration of driver pages
>> Non-lru pages are also migrated with lru pages by move_to_new_page().
>
> The whole patchset looks good.
>
> Reviewed-by: Konstantin Khlebnikov 
>
>>
>> This patch set is tested:
>> - turn on Ubuntu 14.04 with 1G memory on qemu.
>> - do kernel building
>> - after several seconds check more than 512MB is used with free command
>> - command "balloon 512" in qemu monitor
>> - check hundreds MB of pages are migrated
>
> Another simple test is several instances of
> tools/testing/selftests/vm/transhuge-stress.c
> runnng in parallel with balloon inflating/deflating.
> (transparent huge pages must be enabled of course)
> That catched a lot of races in ballooning code.
>

Great!
I'll do it and inform you the result in this week.


[PATCH 4/4] mm: remove direct calling of migration

2015-07-13 Thread Gioh Kim
From: Gioh Kim <guru...@hanmail.net>

Migration is completely generalized so that migrating mobile page
is processed with lru-pages in move_to_new_page.

Signed-off-by: Gioh Kim 
Acked-by: Rafael Aquini 
---
 mm/migrate.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/mm/migrate.c b/mm/migrate.c
index 53f0081d..e6644ac 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -844,21 +844,6 @@ static int __unmap_and_move(struct page *page, struct page 
*newpage,
}
}

-   if (unlikely(mobile_page(page))) {
-   /*
-* A mobile page does not need any special attention from
-* physical to virtual reverse mapping procedures.
-* Skip any attempt to unmap PTEs or to remap swap cache,
-* in order to avoid burning cycles at rmap level, and perform
-* the page migration right away (proteced by page lock).
-*/
-   lock_page(newpage);
-   rc = page->mapping->a_ops->migratepage(page->mapping,
-  newpage, page, mode);
-   unlock_page(newpage);
-   goto out_unlock;
-   }
-
/*
 * Corner case handling:
 * 1. When a new swap-cache page is read into, it is added to the LRU
-- 
2.1.4



[PATCH 3/4] mm/balloon: apply mobile page migratable into balloon

2015-07-13 Thread Gioh Kim
From: Gioh Kim <guru...@hanmail.net>

Apply mobile page migration into balloon driver.
The balloong driver has an anonymous inode that manages
address_space_operation for page migration.
Compaction calls interfaces of mobile page migration
instead of calling balloon migration directly.

Signed-off-by: Gioh Kim 
Acked-by: Rafael Aquini 
---
 drivers/virtio/virtio_balloon.c|  3 ++
 include/linux/balloon_compaction.h | 15 ++--
 mm/balloon_compaction.c| 72 --
 mm/compaction.c|  8 ++---
 mm/migrate.c   | 21 ++-
 5 files changed, 54 insertions(+), 65 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 82e80e0..ef5b9b5 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 

 /*
  * Balloon device works in 4K page units.  So each page is pointed to by
@@ -505,6 +506,8 @@ static int virtballoon_probe(struct virtio_device *vdev)
balloon_devinfo_init(>vb_dev_info);
 #ifdef CONFIG_BALLOON_COMPACTION
vb->vb_dev_info.migratepage = virtballoon_migratepage;
+   vb->vb_dev_info.inode = anon_inode_new();
+   vb->vb_dev_info.inode->i_mapping->a_ops = _aops;
 #endif

err = init_vqs(vb);
diff --git a/include/linux/balloon_compaction.h 
b/include/linux/balloon_compaction.h
index 9b0a15d..a9e0bde 100644
--- a/include/linux/balloon_compaction.h
+++ b/include/linux/balloon_compaction.h
@@ -48,6 +48,7 @@
 #include 
 #include 
 #include 
+#include 

 /*
  * Balloon device information descriptor.
@@ -62,6 +63,7 @@ struct balloon_dev_info {
struct list_head pages; /* Pages enqueued & handled to Host */
int (*migratepage)(struct balloon_dev_info *, struct page *newpage,
struct page *page, enum migrate_mode mode);
+   struct inode *inode;
 };

 extern struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info);
@@ -73,12 +75,16 @@ static inline void balloon_devinfo_init(struct 
balloon_dev_info *balloon)
spin_lock_init(>pages_lock);
INIT_LIST_HEAD(>pages);
balloon->migratepage = NULL;
+   balloon->inode = NULL;
 }

 #ifdef CONFIG_BALLOON_COMPACTION
-extern bool balloon_page_isolate(struct page *page);
+extern const struct address_space_operations balloon_aops;
+extern bool balloon_page_isolate(struct page *page,
+isolate_mode_t mode);
 extern void balloon_page_putback(struct page *page);
-extern int balloon_page_migrate(struct page *newpage,
+extern int balloon_page_migrate(struct address_space *mapping,
+   struct page *newpage,
struct page *page, enum migrate_mode mode);

 /*
@@ -124,6 +130,7 @@ static inline void balloon_page_insert(struct 
balloon_dev_info *balloon,
   struct page *page)
 {
__SetPageBalloon(page);
+   page->mapping = balloon->inode->i_mapping;
SetPagePrivate(page);
set_page_private(page, (unsigned long)balloon);
list_add(>lru, >pages);
@@ -140,6 +147,7 @@ static inline void balloon_page_insert(struct 
balloon_dev_info *balloon,
 static inline void balloon_page_delete(struct page *page)
 {
__ClearPageBalloon(page);
+   page->mapping = NULL;
set_page_private(page, 0);
if (PagePrivate(page)) {
ClearPagePrivate(page);
@@ -191,7 +199,8 @@ static inline bool isolated_balloon_page(struct page *page)
return false;
 }

-static inline bool balloon_page_isolate(struct page *page)
+static inline bool balloon_page_isolate(struct page *page,
+   isolate_mode_t mode)
 {
return false;
 }
diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
index fcad832..8fbcf9c 100644
--- a/mm/balloon_compaction.c
+++ b/mm/balloon_compaction.c
@@ -131,43 +131,16 @@ static inline void __putback_balloon_page(struct page 
*page)
 }

 /* __isolate_lru_page() counterpart for a ballooned page */
-bool balloon_page_isolate(struct page *page)
+bool balloon_page_isolate(struct page *page, isolate_mode_t mode)
 {
/*
-* Avoid burning cycles with pages that are yet under __free_pages(),
-* or just got freed under us.
-*
-* In case we 'win' a race for a balloon page being freed under us and
-* raise its refcount preventing __free_pages() from doing its job
-* the put_page() at the end of this block will take care of
-* release this page, thus avoiding a nasty leakage.
+* A ballooned page, by default, has PagePrivate set.
+* Prevent concurrent compaction threads from isolating
+* an already isolated balloon page by clearing it.
 */
-   if (likely(get_page_unless_zero(page))

[PATCH 2/4] mm/compaction: enable mobile-page migration

2015-07-13 Thread Gioh Kim
From: Gioh Kim <guru...@hanmail.net>

Add framework to register callback functions and check page mobility.
There are some modes for page isolation so that isolate interface
has arguments of page address and isolation mode while putback
interface has only page address as argument.

Signed-off-by: Gioh Kim 
Acked-by: Rafael Aquini 
---
 fs/proc/page.c |  3 ++
 include/linux/compaction.h | 80 ++
 include/linux/fs.h |  2 +
 include/linux/page-flags.h | 19 
 include/uapi/linux/kernel-page-flags.h |  1 +
 5 files changed, 105 insertions(+)

diff --git a/fs/proc/page.c b/fs/proc/page.c
index 7eee2d8..a4f5a00 100644
--- a/fs/proc/page.c
+++ b/fs/proc/page.c
@@ -146,6 +146,9 @@ u64 stable_page_flags(struct page *page)
if (PageBalloon(page))
u |= 1 << KPF_BALLOON;

+   if (PageMobile(page))
+   u |= 1 << KPF_MOBILE;
+
u |= kpf_copy_bit(k, KPF_LOCKED,PG_locked);

u |= kpf_copy_bit(k, KPF_SLAB,  PG_slab);
diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index aa8f61c..f693072 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -1,6 +1,9 @@
 #ifndef _LINUX_COMPACTION_H
 #define _LINUX_COMPACTION_H

+#include 
+#include 
+
 /* Return values for compact_zone() and try_to_compact_pages() */
 /* compaction didn't start as it was deferred due to past failures */
 #define COMPACT_DEFERRED   0
@@ -51,6 +54,70 @@ extern void compaction_defer_reset(struct zone *zone, int 
order,
bool alloc_success);
 extern bool compaction_restarting(struct zone *zone, int order);

+static inline bool mobile_page(struct page *page)
+{
+   return page->mapping && (PageMobile(page) || PageBalloon(page));
+}
+
+static inline bool isolate_mobilepage(struct page *page, isolate_mode_t mode)
+{
+   bool ret = false;
+
+   /*
+* Avoid burning cycles with pages that are yet under __free_pages(),
+* or just got freed under us.
+*
+* In case we 'win' a race for a mobile page being freed under us and
+* raise its refcount preventing __free_pages() from doing its job
+* the put_page() at the end of this block will take care of
+* release this page, thus avoiding a nasty leakage.
+*/
+   if (unlikely(!get_page_unless_zero(page)))
+   goto out;
+
+   /*
+* As mobile pages are not isolated from LRU lists, concurrent
+* compaction threads can race against page migration functions
+* as well as race against the releasing a page.
+*
+* In order to avoid having an already isolated mobile page
+* being (wrongly) re-isolated while it is under migration,
+* or to avoid attempting to isolate pages being released,
+* lets be sure we have the page lock
+* before proceeding with the mobile page isolation steps.
+*/
+   if (unlikely(!trylock_page(page)))
+   goto out_putpage;
+
+   if (!(mobile_page(page) && page->mapping->a_ops->isolatepage))
+   goto out_not_isolated;
+   ret = page->mapping->a_ops->isolatepage(page, mode);
+   if (!ret)
+   goto out_not_isolated;
+   unlock_page(page);
+   return ret;
+
+out_not_isolated:
+   unlock_page(page);
+out_putpage:
+   put_page(page);
+out:
+   return ret;
+}
+
+static inline void putback_mobilepage(struct page *page)
+{
+   /*
+* 'lock_page()' stabilizes the page and prevents races against
+* concurrent isolation threads attempting to re-isolate it.
+*/
+   lock_page(page);
+   if (page->mapping && page->mapping->a_ops->putbackpage)
+   page->mapping->a_ops->putbackpage(page);
+   unlock_page(page);
+   /* drop the extra ref count taken for mobile page isolation */
+   put_page(page);
+}
 #else
 static inline unsigned long try_to_compact_pages(gfp_t gfp_mask,
unsigned int order, int alloc_flags,
@@ -83,6 +150,19 @@ static inline bool compaction_deferred(struct zone *zone, 
int order)
return true;
 }

+static inline bool mobile_page(struct page *page)
+{
+   return false;
+}
+
+static inline bool isolate_mobilepage(struct page *page, isolate_mode_t mode)
+{
+   return false;
+}
+
+static inline void putback_mobilepage(struct page *page)
+{
+}
 #endif /* CONFIG_COMPACTION */

 #if defined(CONFIG_COMPACTION) && defined(CONFIG_SYSFS) && defined(CONFIG_NUMA)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index a0653e5..2cc4b24 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -396,6 +396,8 @@ struct address_space_operations {
 */
int (*migratepage) (struct address_space *,
  

[PATCH 1/4] fs/anon_inodes: new interface to create new inode

2015-07-13 Thread Gioh Kim
From: Gioh Kim <guru...@hanmail.net>

The anon_inodes has already complete interfaces to create manage
many anonymous inodes but don't have interface to get
new inode. Other sub-modules can create anonymous inode
without creating and mounting it's own pseudo filesystem.

Signed-off-by: Gioh Kim 
Acked-by: Rafael Aquini 
---
 fs/anon_inodes.c| 6 ++
 include/linux/anon_inodes.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index 80ef38c..1d51f96 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -162,6 +162,12 @@ err_put_unused_fd:
 }
 EXPORT_SYMBOL_GPL(anon_inode_getfd);

+struct inode *anon_inode_new(void)
+{
+   return alloc_anon_inode(anon_inode_mnt->mnt_sb);
+}
+EXPORT_SYMBOL_GPL(anon_inode_new);
+
 static int __init anon_inode_init(void)
 {
anon_inode_mnt = kern_mount(_inode_fs_type);
diff --git a/include/linux/anon_inodes.h b/include/linux/anon_inodes.h
index 8013a45..ddbd67f 100644
--- a/include/linux/anon_inodes.h
+++ b/include/linux/anon_inodes.h
@@ -15,6 +15,7 @@ struct file *anon_inode_getfile(const char *name,
void *priv, int flags);
 int anon_inode_getfd(const char *name, const struct file_operations *fops,
 void *priv, int flags);
+struct inode *anon_inode_new(void);

 #endif /* _LINUX_ANON_INODES_H */

-- 
2.1.4



[PATCH 0/4] enable migration of driver pages

2015-07-13 Thread Gioh Kim
From: Gioh Kim <guru...@hanmail.net>

Hello,

This series try to enable migration of non-LRU pages, such as driver's page.

My ARM-based platform occured severe fragmentation problem after long-term
(several days) test. Sometimes even order-3 page allocation failed. It has
memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing
and 20~30 memory is reserved for zram.

I found that many pages of GPU driver and zram are non-movable pages. So I
reported Minchan Kim, the maintainer of zram, and he made the internal 
compaction logic of zram. And I made the internal compaction of GPU driver.

They reduced some fragmentation but they are not enough effective.
They are activated by its own interface, /sys, so they are not cooperative
with kernel compaction. If there is too much fragmentation and kernel starts
to compaction, zram and GPU driver cannot work with the kernel compaction.

So I thought there needs a interface to combine driver and kernel compaction.
This patch adds a generic isolate/migrate/putback callbacks for page
address-space and a new interface to create anon-inode to manage
address_space_operation. The zram and GPU, and any other modules can create
anon_inode and register its own migration method. The kernel compaction can
call the registered migration when it does compaction.

My GPU driver source is not in-kernel driver so that I apply the interface
into balloon driver. The balloon driver is already merged
into the kernel compaction as a corner-case. This patch have the balloon
driver migration be called by the generic interface.


This patch set combines 4 patches.

1. patch 1/4: get inode from anon_inodes
This patch adds new interface to create inode from anon_inodes.

2. patch 2/4: framework to isolate/migrate/putback page
Add isolatepage, putbackpage into address_space_operations
and wrapper function to call them.

3. patch 3/4: apply the framework into balloon driver
The balloon driver is applied into the framework. It gets a inode
from anon_inodes and register operations in the inode.
The kernel compaction calls generic interfaces, not balloon
driver interfaces. 
Any other drivers can register operations via inode like this
to migrate it's pages.

4. patch 4/4: remove direct calling of migration of driver pages
Non-lru pages are also migrated with lru pages by move_to_new_page().

This patch set is tested:
- turn on Ubuntu 14.04 with 1G memory on qemu.
- do kernel building
- after several seconds check more than 512MB is used with free command
- command "balloon 512" in qemu monitor
- check hundreds MB of pages are migrated

My thanks to Konstantin Khlebnikov for his reviews of the RFC patch set.
Most of the changes were based on his feedback.

This patch-set is based on v4.1


Gioh Kim (4):
  fs/anon_inodes: new interface to create new inode
  mm/compaction: enable mobile-page migration
  mm/balloon: apply mobile page migratable into balloon
  mm: remove direct calling of migration

 drivers/virtio/virtio_balloon.c|  3 ++
 fs/anon_inodes.c   |  6 +++
 fs/proc/page.c |  3 ++
 include/linux/anon_inodes.h|  1 +
 include/linux/balloon_compaction.h | 15 +--
 include/linux/compaction.h | 80 ++
 include/linux/fs.h |  2 +
 include/linux/page-flags.h | 19 
 include/uapi/linux/kernel-page-flags.h |  1 +
 mm/balloon_compaction.c| 72 ++
 mm/compaction.c|  8 ++--
 mm/migrate.c   | 24 +++---
 12 files changed, 160 insertions(+), 74 deletions(-)

-- 
2.1.4



[RFCv3 0/5] enable migration of driver pages

2015-07-10 Thread Gioh Kim


2015-07-09 오후 10:08에 Daniel Vetter 이(가) 쓴 글:
> Also there's a bit a lack of gpu drivers from the arm world in upstream,
> which is probabyl why this patch series doesn't come with a user. Might be
> better to first upstream the driver before talking about additional
> infrastructure that it needs.
> -Daniel

I'm not from ARM but I just got the idea of driver page migration
during I worked with ARM gpu driver.
I'm sure this patch is good for zram and balloon
and hope it can be applied to drivers consuming many pages and generating 
fragmentation,
such as GPU or gfx driver.


[RFCv3 0/5] enable migration of driver pages

2015-07-09 Thread Gioh Kim


2015-07-09 오전 7:47에 Dave Airlie 이(가) 쓴 글:
>>>
>>>
>>> Can the various in-kernel GPU drivers benefit from this?  If so, wiring
>>> up one or more of those would be helpful?
>>
>>
>> I'm sure that other in-kernel GPU drivers can have benefit.
>> It must be helpful.
>>
>> If I was familiar with other in-kernel GPU drivers code, I tried to patch
>> them.
>> It's too bad.
>
> I'll bring dri-devel into the loop here.
>
> ARM GPU developers please take a look at this stuff, Laurent, Rob,
> Eric I suppose.

I sent a patch, https://lkml.org/lkml/2015/3/24/1182, and my opinion about 
compaction
to ARM GPU developers via Korea ARM branch.
I got a reply that they had no time to review it.

I hope they're interested to this patch.


>
> Daniel Vetter you might have some opinions as well.
>
> Dave.
>


[RFC] background zero-set page for device

2014-12-19 Thread Gioh Kim

There was some discussion to create zero-set pages in background like this:
https://lkml.org/lkml/2004/10/30/73

I'm understand that it is not good for performance.

But I think it can help for a device in my platform.
I'm sorry I can't tell what it is.
But the device needs many zero-set pages, up to several MB,
so that device driver has a loop to calls alloc_page, memset(p, 0, PAGE_SIZE) 
and cache flush
And the device uses the pages and returns it to kernel. Kernel reads data in 
the page.

In this case, memset(0) must be done.
I think, if memset(0) is done at idle time, it can remove memset calling of ddk.

Is there any device that needs many zero-set pages?
Can backgound zero-setting page be good for the device?

-- 
Thanks,
Gioh Kim


[PATCH] Documentation/dma-buf-sharing.txt: update API descriptions

2014-05-14 Thread Gioh Kim
Thank you for advice.
I will send a fixed patch soon.

> -Original Message-
> From: Thierry Reding [mailto:thierry.reding at gmail.com]
> Sent: Tuesday, May 13, 2014 5:45 PM
> To: gioh.kim
> Cc: Sumit Semwal; Randy Dunlap; linux-media at vger.kernel.org; dri-devel at 
> lists.freedesktop.org; linux-
> doc at vger.kernel.org; linux-kernel at vger.kernel.org; gunho.lee at lge.com
> Subject: Re: [PATCH] Documentation/dma-buf-sharing.txt: update API 
> descriptions
> 
> On Mon, May 12, 2014 at 08:48:12PM +0900, gioh.kim wrote:
> > From: "gioh.kim" 
> 
> It might be good to fix your setup to make this be the same as the name
> and email used in the Signed-off-by line below.
> 
> > update some descriptions for API arguments and descriptions.
> 
> Nit: "Update" since it's the beginning of a sentence.
> 
> > Signed-off-by: Gioh Kim 
> > ---
> >  Documentation/dma-buf-sharing.txt |   10 ++
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/dma-buf-sharing.txt 
> > b/Documentation/dma-buf-sharing.txt
> > index 505e711..1ea89b8 100644
> > --- a/Documentation/dma-buf-sharing.txt
> > +++ b/Documentation/dma-buf-sharing.txt
> > @@ -56,7 +56,7 @@ The dma_buf buffer sharing API usage contains the 
> > following steps:
> >  size_t size, int flags,
> >  const char *exp_name)
> >
> > -   If this succeeds, dma_buf_export allocates a dma_buf structure, and 
> > returns a
> > +   If this succeeds, dma_buf_export_named allocates a dma_buf structure, 
> > and returns a
> 
> Perhaps reformat this so that the lines don't exceed 80 characters?
> 
> > pointer to the same. It also associates an anonymous file with this 
> > buffer,
> > so it can be exported. On failure to allocate the dma_buf object, it 
> > returns
> > NULL.
> > @@ -66,7 +66,7 @@ The dma_buf buffer sharing API usage contains the 
> > following steps:
> >
> > Exporting modules which do not wish to provide any specific name may 
> > use the
> > helper define 'dma_buf_export()', with the same arguments as above, but
> > -   without the last argument; a __FILE__ pre-processor directive will be
> > +   without the last argument; a KBUILD_MODNAME pre-processor directive 
> > will be
> > inserted in place of 'exp_name' instead.
> 
> This was already fixed in commit 2e33def0339c (dma-buf: update exp_name
> when using dma_buf_export()). Perhaps you should rebase this patch on
> top of the latest linux-next.
> 
> Otherwise looks good.
> 
> Thierry



[PATCH] Documentation/dma-buf-sharing.txt: update API descriptions

2014-05-14 Thread Gioh Kim
Update some descriptions for API arguments and descriptions.

Signed-off-by: Gioh Kim 
---
 Documentation/dma-buf-sharing.txt |   14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 505e711..aadd901 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -56,10 +56,10 @@ The dma_buf buffer sharing API usage contains the following 
steps:
 size_t size, int flags,
 const char *exp_name)

-   If this succeeds, dma_buf_export allocates a dma_buf structure, and returns 
a
-   pointer to the same. It also associates an anonymous file with this buffer,
-   so it can be exported. On failure to allocate the dma_buf object, it returns
-   NULL.
+   If this succeeds, dma_buf_export_named allocates a dma_buf structure, and
+   returns a pointer to the same. It also associates an anonymous file with 
this
+   buffer, so it can be exported. On failure to allocate the dma_buf object,
+   it returns NULL.

'exp_name' is the name of exporter - to facilitate information while
debugging.
@@ -76,7 +76,7 @@ The dma_buf buffer sharing API usage contains the following 
steps:
drivers and/or processes.

Interface:
-  int dma_buf_fd(struct dma_buf *dmabuf)
+  int dma_buf_fd(struct dma_buf *dmabuf, int flags)

This API installs an fd for the anonymous file associated with this buffer;
returns either 'fd', or error.
@@ -157,7 +157,9 @@ to request use of buffer for allocation.
"dma_buf->ops->" indirection from the users of this interface.

In struct dma_buf_ops, unmap_dma_buf is defined as
-  void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *);
+  void (*unmap_dma_buf)(struct dma_buf_attachment *,
+struct sg_table *,
+enum dma_data_direction);

unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like
map_dma_buf, this API also must be implemented by the exporter.
-- 
1.7.9.5