On 06/02/2016 02:25 AM, Minchan Kim wrote:
On Wed, Jun 01, 2016 at 04:09:26PM +0200, Vlastimil Babka wrote:
On 06/01/2016 01:21 AM, Minchan Kim wrote:
+ reset_page(page);
+ put_page(page);
+ page = newpage;
+
+ ret = 0;
+unpin_objects:
+ for (addr = s_addr + offset
On Wed, Jun 01, 2016 at 04:09:26PM +0200, Vlastimil Babka wrote:
> On 06/01/2016 01:21 AM, Minchan Kim wrote:
>
> [...]
>
> >
> > Cc: Sergey Senozhatsky
> > Signed-off-by: Minchan Kim
>
> I'm not that familiar with zsmalloc, so this is not a full review. I was
> just curious how it's handling
On Wed, Jun 01, 2016 at 02:39:36PM -0700, Andrew Morton wrote:
> On Wed, 1 Jun 2016 08:21:20 +0900 Minchan Kim wrote:
>
> > This patch introduces run-time migration feature for zspage.
> >
> > ...
> >
> > +static void kick_deferred_free(struct zs_pool *pool)
> > +{
> > + schedule_work(&pool->
On Wed, 1 Jun 2016 08:21:20 +0900 Minchan Kim wrote:
> This patch introduces run-time migration feature for zspage.
>
> ...
>
> +static void kick_deferred_free(struct zs_pool *pool)
> +{
> + schedule_work(&pool->free_work);
> +}
When CONFIG_ZSMALLOC=m, what keeps all the data structures in
On 06/01/2016 01:21 AM, Minchan Kim wrote:
[...]
>
> Cc: Sergey Senozhatsky
> Signed-off-by: Minchan Kim
I'm not that familiar with zsmalloc, so this is not a full review. I was
just curious how it's handling the movable migration API, and stumbled
upon some things pointed out below.
> @@ -2
This patch introduces run-time migration feature for zspage.
For migration, VM uses page.lru field so it would be better to not use
page.next field which is unified with page.lru for own purpose.
For that, firstly, we can get first object offset of the page via
runtime calculation instead of using
6 matches
Mail list logo
