From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlastimil Babka Subject: Re: [PATCH v3 02/16] mm/compaction: support non-lru movable page migration Date: Mon, 4 Apr 2016 15:24:34 +0200 Message-ID: <57026B12.6060000@suse.cz> References: <1459321935-3655-1-git-send-email-minchan@kernel.org> <1459321935-3655-3-git-send-email-minchan@kernel.org> <56FEE82A.30602@suse.cz> <20160404051225.GA6838@bbox> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by gabe.freedesktop.org (Postfix) with ESMTPS id A2D146E515 for ; Mon, 4 Apr 2016 13:24:38 +0000 (UTC) In-Reply-To: <20160404051225.GA6838@bbox> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Minchan Kim Cc: jlayton@poochiereds.net, Rik van Riel , YiPing Xu , aquini@redhat.com, rknize@motorola.com, Sergey Senozhatsky , Chan Gyun Jeong , Hugh Dickins , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, virtualization@lists.linux-foundation.org, bfields@fieldses.org, linux-mm@kvack.org, Gioh Kim , Gioh Kim , Mel Gorman , Sangseok Lee , Andrew Morton , Joonsoo Kim , koct9i@gmail.com, Al Viro List-Id: dri-devel@lists.freedesktop.org T24gMDQvMDQvMjAxNiAwNzoxMiBBTSwgTWluY2hhbiBLaW0gd3JvdGU6Cj4gT24gRnJpLCBBcHIg MDEsIDIwMTYgYXQgMTE6Mjk6MTRQTSArMDIwMCwgVmxhc3RpbWlsIEJhYmthIHdyb3RlOgo+PiBN aWdodCBoYXZlIGJlZW4gYmV0dGVyIGFzIGEgc2VwYXJhdGUgbWlncmF0aW9uIHBhdGNoIGFuZCB0 aGVuIGEKPj4gY29tcGFjdGlvbiBwYXRjaC4gSXQncyBwcmVmaXhlZCBtbS9jb21wYWN0aW9uLCBi dXQgbW9zdCBjaGFuZ2VkIGFyZQo+PiBpbiBtbS9taWdyYXRlLmMKPgo+IEluZGVlZC4gVGhlIHRp dGxlIGlzIHJhdGhlciBtaXNsZWFkaW5nIGJ1dCBub3Qgc3VyZSBpdCdzIGEgZ29vZCBpZGVhCj4g dG8gc2VwYXJhdGUgY29tcGFjdGlvbiBhbmQgbWlncmF0aW9uIHBhcnQuCgpHdWVzcyBpdCdzIGJl dHRlciB0byBzZWUgdGhlIG5ldyBmdW5jdGlvbnMgdG9nZXRoZXIgd2l0aCBpdHMgdXNlciBhZnRl ciAKYWxsLCBPSy4KCj4gSSB3aWxsIGp1c3QgcmVzZW5kIHRvIGNoYW5nZSB0aGUgdGlsZSBmcm9t ICJtbS9jb21wYWN0aW9uIiB0bwo+ICJtbS9taWdyYXRpb24iLgoKT0shCgo+PiBBbHNvIEknbSBh IGJpdCB1bmNvbWZvcnRhYmxlIGhvdyBpc29sYXRlX21vdmFibGVfcGFnZSgpIGJsaW5kbHkgZXhw ZWN0cyB0aGF0Cj4+IHBhZ2UtPm1hcHBpbmctPmFfb3BzLT5pc29sYXRlX3BhZ2UgZXhpc3RzIGZv ciBQYWdlTW92YWJsZSgpIHBhZ2VzLgo+PiBXaGF0IGlmIGl0J3MgYSBmYWxzZSBwb3NpdGl2ZSBv biBhIFBHX3JlY2xhaW0gcGFnZT8gQ2FuIHdlIHJlbHkgb24KPj4gUEdfcmVjbGFpbSBhbHdheXMg KGFuZCB3aXRob3V0IHJhY2VzKSBpbXBseWluZyBQYWdlTFJVKCkgc28gdGhhdCB3ZQo+PiBkb24n dCBldmVuIGF0dGVtcHQgaXNvbGF0ZV9tb3ZhYmxlX3BhZ2UoKT8KPgo+IEZvciBub3csIHdlIHNo b3VsZG4ndCBoYXZlIHN1Y2ggYSBmYWxzZSBwb3NpdGl2ZSBiZWNhdXNlIFBhZ2VNb3ZhYmxlCj4g Y2hlY2tzIHBhZ2UtPl9tYXBjb3VudCA9PSBQQUdFX01PVkFCTEVfTUFQQ09VTlRfVkFMVUUgYXMg d2VsbCBhcyBQR19tb3ZhYmxlCj4gdW5kZXIgUEdfbG9jay4KPgo+IEJ1dCBJIHJlYWQgeW91ciBx dWVzdGlvbiBhYm91dCB1c2VyLW1hcHBlZCBkcnZpZXIgcGFnZXMgc28gd2UgY2Fubm90Cj4gdXNl IF9tYXBjb3VudCBhbnltb3JlIHNvIEkgd2lsbCBmaW5kIGFub3RoZXIgdGhpbmcuIEEgb3B0aW9u IGlzIHRoaXMuCj4KPiBzdGF0aWMgaW5saW5lIGludCBQYWdlTW92YWJsZShzdHJ1Y3QgcGFnZSAq cGFnZSkKPiB7Cj4gICAgICAgICAgaW50IHJldCA9IDA7Cj4gICAgICAgICAgc3RydWN0IGFkZHJl c3Nfc3BhY2UgKm1hcHBpbmc7Cj4gICAgICAgICAgc3RydWN0IGFkZHJlc3Nfc3BhY2Vfb3BlcmF0 aW9ucyAqYV9vcDsKPgo+ICAgICAgICAgIGlmICghdGVzdF9iaXQoUEdfbW92YWJsZSwgJihwYWdl LT5mbGFncykpCj4gICAgICAgICAgICAgICAgICBnb3RvIG91dDsKPgo+ICAgICAgICAgIG1hcHBp bmcgPSBwYWdlLT5tYXBwaW5nOwo+ICAgICAgICAgIGlmICghbWFwcGluZykKPiAgICAgICAgICAg ICAgICAgIGdvdG8gb3V0Owo+Cj4gICAgICAgICAgYV9vcCA9IG1hcHBpbmctPmFfb3A7Cj4gICAg ICAgICAgaWYgKCFhb3ApCj4gICAgICAgICAgICAgICAgICBnb3RvIG91dDsKPiAgICAgICAgICBp ZiAoYV9vcC0+aXNvbGF0ZV9wYWdlKQo+ICAgICAgICAgICAgICAgICAgcmV0ID0gMTsKPiBvdXQ6 Cj4gICAgICAgICAgcmV0dXJuIHJldDsKPgo+IH0KPgo+IEl0IHdvcmtzIHVuZGVyIFBHX2xvY2sg YnV0IHdpdGggdGhpcywgd2UgbmVlZCB0cnlsb2NrX3BhZ2UgdG8gcGVlawo+IHdoZXRoZXIgaXQn cyBtb3ZhYmxlIG5vbi1scnUgb3Igbm90IGZvciBzY2FubmluZyBwZm4uCgpIbSBJIGhvcGVkIHRo YXQgd2l0aCBSRUFEX09OQ0UoKSB3ZSBjb3VsZCBkbyB0aGUgcGVlayBzYWZlbHkgd2l0aG91dCAK dHJ5bG9ja19wYWdlLCBpZiB3ZSB1c2UgaXQgb25seSBhcyBhIGhldXJpc3RpYy4gQnV0IEkgZ3Vl c3MgaXQgd291bGQgCnJlcXVpcmUgYXQgbGVhc3QgUkNVLWxldmVsIHByb3RlY3Rpb24gb2YgdGhl IApwYWdlLT5tYXBwaW5nLT5hX29wLT5pc29sYXRlX3BhZ2UgY2hhaW4uCgo+IEZvciBhdm9pZGlu ZyB0aGF0LCB3ZSBuZWVkIGFub3RoZXIgZnVuY3Rpb24gdG8gcGVlayB3aGljaCBqdXN0IGNoZWNr cwo+IFBHX21vdmFibGUgYml0IGluc3RlYWQgb2YgYWxsIHRoaW5ncy4KPgo+Cj4gLyoKPiAgICog SWYgQHBhZ2VfbG9ja2VkIGlzIGZhbHNlLCB3ZSBjYW5ub3QgZ3VhcmFudGVlIHBhZ2UtPm1hcHBp bmcncyBzdGFiaWxpdHkKPiAgICogc28ganVzdCB0aGUgZnVuY3Rpb24gY2hlY2tzIHdpdGggUEdf bW92YWJsZSB3aGljaCBjb3VsZCBiZSBmYWxzZSBwb3NpdGl2ZQo+ICAgKiBzbyBjYWxsZXIgc2hv dWxkIGNoZWNrIGl0IGFnYWluIHVuZGVyIFBHX2xvY2sgdG8gY2hlY2sgYV9vcHMtPmlzb2xhdGVf cGFnZS4KPiAgICovCj4gc3RhdGljIGlubGluZSBpbnQgUGFnZU1vdmFibGUoc3RydWN0IHBhZ2Ug KnBhZ2UsIGJvb2wgcGFnZV9sb2NrZWQpCj4gewo+ICAgICAgICAgIGludCByZXQgPSAwOwo+ICAg ICAgICAgIHN0cnVjdCBhZGRyZXNzX3NwYWNlICptYXBwaW5nOwo+ICAgICAgICAgIHN0cnVjdCBh ZGRyZXNzX3NwYWNlX29wZXJhdGlvbnMgKmFfb3A7Cj4KPiAgICAgICAgICBpZiAoIXRlc3RfYml0 KFBHX21vdmFibGUsICYocGFnZS0+ZmxhZ3MpKQo+ICAgICAgICAgICAgICAgICAgZ290byBvdXQ7 Cj4KPiAgICAgICAgICBpZiAoIXBhZ2VfbG9ja2VkKSB7Cj4gICAgICAgICAgICAgICAgICByZXQg PSAxOwo+ICAgICAgICAgICAgICAgICAgZ290byBvdXQ7Cj4gICAgICAgICAgfQo+Cj4gICAgICAg ICAgbWFwcGluZyA9IHBhZ2UtPm1hcHBpbmc7Cj4gICAgICAgICAgaWYgKCFtYXBwaW5nKQo+ICAg ICAgICAgICAgICAgICAgZ290byBvdXQ7Cj4KPiAgICAgICAgICBhX29wID0gbWFwcGluZy0+YV9v cDsKPiAgICAgICAgICBpZiAoIWFvcCkKPiAgICAgICAgICAgICAgICAgIGdvdG8gb3V0Owo+ICAg ICAgICAgIGlmIChhX29wLT5pc29sYXRlX3BhZ2UpCj4gICAgICAgICAgICAgICAgICByZXQgPSAx Owo+IG91dDoKPiAgICAgICAgICByZXR1cm4gcmV0Owo+IH0KCkkgd291bGRuJ3QgcHV0IGV2ZXJ5 dGhpbmcgaW50byBzaW5nbGUgZnVuY3Rpb24sIGJ1dCBjcmVhdGUgc29tZXRoaW5nIApsaWtlIF9f UGFnZU1vdmFibGUoKSBqdXN0IGZvciB0aGUgdW5sb2NrZWQgcGVlay4gVW5saWtlIHRoZSAKem9u ZS0+bHJ1X2xvY2ssIHdlIGRvbid0IGtlZXAgcGFnZV9sb2NrKCkgYWNyb3NzIGl0ZXJhdGlvbnMg aW4gCmlzb2xhdGVfbWlncmF0ZXBhZ2VzX2Jsb2NrKCksIGFzIG9idmlvdXNseSBlYWNoIHBhZ2Ug aGFzIGRpZmZlcmVudCBsb2NrLgpTbyB0aGUgcGFnZV9sb2NrZWQgcGFyYW1ldGVyIHdvdWxkIGJl IGFsd2F5cyBwYXNzZWQgYXMgY29uc3RhbnQsIGFuZCBhdCAKdGhhdCBwb2ludCBpdCdzIGJldHRl ciB0byBoYXZlIHNlcGFyYXRlIGZ1bmN0aW9ucy4KClNvIEkgZ3Vlc3MgdGhlIHF1ZXN0aW9uIGlz IGhvdyBtYW55IGZhbHNlIHBvc2l0aXZlcyBmcm9tIG92ZXJsYXAgd2l0aCAKUEdfcmVjbGFpbSB0 aGUgc2Nhbm5lciB3aWxsIGhpdCBpZiB3ZSBnaXZlIHVwIG9uIApQQUdFX01PVkFCTEVfTUFQQ09V TlRfVkFMVUUsIGFzIHRoYXQgd2lsbCBpbmNyZWFzZSBudW1iZXIgb2YgcGFnZSBsb2NrcyAKanVz dCB0byByZWFsaXplIHRoYXQgaXQncyBub3QgYWN0dWFsIFBhZ2VNb3ZhYmxlKCkgcGFnZS4uLgoK PiBUaGFua3MgZm9yIGRldGFpbCByZXZpZXcsIFZsYXN0aW1pbCEKPiBJIHdpbGwgcmVzZW5kIG5l dyB2ZXJzaW9ucyBhZnRlciB2YWNhdGlvbiBpbiB0aGlzIHdlZWsuCgpZb3UncmUgd2VsY29tZSwg Z3JlYXQhCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRy aS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRw czovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by kanga.kvack.org (Postfix) with ESMTP id DF4436B027B for ; Mon, 4 Apr 2016 09:24:38 -0400 (EDT) Received: by mail-lb0-f173.google.com with SMTP id u8so161054731lbk.0 for ; Mon, 04 Apr 2016 06:24:38 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id vl10si31260508wjc.75.2016.04.04.06.24.37 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 04 Apr 2016 06:24:37 -0700 (PDT) Subject: Re: [PATCH v3 02/16] mm/compaction: support non-lru movable page migration References: <1459321935-3655-1-git-send-email-minchan@kernel.org> <1459321935-3655-3-git-send-email-minchan@kernel.org> <56FEE82A.30602@suse.cz> <20160404051225.GA6838@bbox> From: Vlastimil Babka Message-ID: <57026B12.6060000@suse.cz> Date: Mon, 4 Apr 2016 15:24:34 +0200 MIME-Version: 1.0 In-Reply-To: <20160404051225.GA6838@bbox> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, jlayton@poochiereds.net, bfields@fieldses.org, Joonsoo Kim , koct9i@gmail.com, aquini@redhat.com, virtualization@lists.linux-foundation.org, Mel Gorman , Hugh Dickins , Sergey Senozhatsky , Rik van Riel , rknize@motorola.com, Gioh Kim , Sangseok Lee , Chan Gyun Jeong , Al Viro , YiPing Xu , dri-devel@lists.freedesktop.org, Gioh Kim On 04/04/2016 07:12 AM, Minchan Kim wrote: > On Fri, Apr 01, 2016 at 11:29:14PM +0200, Vlastimil Babka wrote: >> Might have been better as a separate migration patch and then a >> compaction patch. It's prefixed mm/compaction, but most changed are >> in mm/migrate.c > > Indeed. The title is rather misleading but not sure it's a good idea > to separate compaction and migration part. Guess it's better to see the new functions together with its user after all, OK. > I will just resend to change the tile from "mm/compaction" to > "mm/migration". OK! >> Also I'm a bit uncomfortable how isolate_movable_page() blindly expects that >> page->mapping->a_ops->isolate_page exists for PageMovable() pages. >> What if it's a false positive on a PG_reclaim page? Can we rely on >> PG_reclaim always (and without races) implying PageLRU() so that we >> don't even attempt isolate_movable_page()? > > For now, we shouldn't have such a false positive because PageMovable > checks page->_mapcount == PAGE_MOVABLE_MAPCOUNT_VALUE as well as PG_movable > under PG_lock. > > But I read your question about user-mapped drvier pages so we cannot > use _mapcount anymore so I will find another thing. A option is this. > > static inline int PageMovable(struct page *page) > { > int ret = 0; > struct address_space *mapping; > struct address_space_operations *a_op; > > if (!test_bit(PG_movable, &(page->flags)) > goto out; > > mapping = page->mapping; > if (!mapping) > goto out; > > a_op = mapping->a_op; > if (!aop) > goto out; > if (a_op->isolate_page) > ret = 1; > out: > return ret; > > } > > It works under PG_lock but with this, we need trylock_page to peek > whether it's movable non-lru or not for scanning pfn. Hm I hoped that with READ_ONCE() we could do the peek safely without trylock_page, if we use it only as a heuristic. But I guess it would require at least RCU-level protection of the page->mapping->a_op->isolate_page chain. > For avoiding that, we need another function to peek which just checks > PG_movable bit instead of all things. > > > /* > * If @page_locked is false, we cannot guarantee page->mapping's stability > * so just the function checks with PG_movable which could be false positive > * so caller should check it again under PG_lock to check a_ops->isolate_page. > */ > static inline int PageMovable(struct page *page, bool page_locked) > { > int ret = 0; > struct address_space *mapping; > struct address_space_operations *a_op; > > if (!test_bit(PG_movable, &(page->flags)) > goto out; > > if (!page_locked) { > ret = 1; > goto out; > } > > mapping = page->mapping; > if (!mapping) > goto out; > > a_op = mapping->a_op; > if (!aop) > goto out; > if (a_op->isolate_page) > ret = 1; > out: > return ret; > } I wouldn't put everything into single function, but create something like __PageMovable() just for the unlocked peek. Unlike the zone->lru_lock, we don't keep page_lock() across iterations in isolate_migratepages_block(), as obviously each page has different lock. So the page_locked parameter would be always passed as constant, and at that point it's better to have separate functions. So I guess the question is how many false positives from overlap with PG_reclaim the scanner will hit if we give up on PAGE_MOVABLE_MAPCOUNT_VALUE, as that will increase number of page locks just to realize that it's not actual PageMovable() page... > Thanks for detail review, Vlastimil! > I will resend new versions after vacation in this week. You're welcome, great! -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755275AbcDDNYk (ORCPT ); Mon, 4 Apr 2016 09:24:40 -0400 Received: from mx2.suse.de ([195.135.220.15]:47169 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751495AbcDDNYj (ORCPT ); Mon, 4 Apr 2016 09:24:39 -0400 Subject: Re: [PATCH v3 02/16] mm/compaction: support non-lru movable page migration To: Minchan Kim References: <1459321935-3655-1-git-send-email-minchan@kernel.org> <1459321935-3655-3-git-send-email-minchan@kernel.org> <56FEE82A.30602@suse.cz> <20160404051225.GA6838@bbox> Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, jlayton@poochiereds.net, bfields@fieldses.org, Joonsoo Kim , koct9i@gmail.com, aquini@redhat.com, virtualization@lists.linux-foundation.org, Mel Gorman , Hugh Dickins , Sergey Senozhatsky , Rik van Riel , rknize@motorola.com, Gioh Kim , Sangseok Lee , Chan Gyun Jeong , Al Viro , YiPing Xu , dri-devel@lists.freedesktop.org, Gioh Kim From: Vlastimil Babka Message-ID: <57026B12.6060000@suse.cz> Date: Mon, 4 Apr 2016 15:24:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160404051225.GA6838@bbox> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/04/2016 07:12 AM, Minchan Kim wrote: > On Fri, Apr 01, 2016 at 11:29:14PM +0200, Vlastimil Babka wrote: >> Might have been better as a separate migration patch and then a >> compaction patch. It's prefixed mm/compaction, but most changed are >> in mm/migrate.c > > Indeed. The title is rather misleading but not sure it's a good idea > to separate compaction and migration part. Guess it's better to see the new functions together with its user after all, OK. > I will just resend to change the tile from "mm/compaction" to > "mm/migration". OK! >> Also I'm a bit uncomfortable how isolate_movable_page() blindly expects that >> page->mapping->a_ops->isolate_page exists for PageMovable() pages. >> What if it's a false positive on a PG_reclaim page? Can we rely on >> PG_reclaim always (and without races) implying PageLRU() so that we >> don't even attempt isolate_movable_page()? > > For now, we shouldn't have such a false positive because PageMovable > checks page->_mapcount == PAGE_MOVABLE_MAPCOUNT_VALUE as well as PG_movable > under PG_lock. > > But I read your question about user-mapped drvier pages so we cannot > use _mapcount anymore so I will find another thing. A option is this. > > static inline int PageMovable(struct page *page) > { > int ret = 0; > struct address_space *mapping; > struct address_space_operations *a_op; > > if (!test_bit(PG_movable, &(page->flags)) > goto out; > > mapping = page->mapping; > if (!mapping) > goto out; > > a_op = mapping->a_op; > if (!aop) > goto out; > if (a_op->isolate_page) > ret = 1; > out: > return ret; > > } > > It works under PG_lock but with this, we need trylock_page to peek > whether it's movable non-lru or not for scanning pfn. Hm I hoped that with READ_ONCE() we could do the peek safely without trylock_page, if we use it only as a heuristic. But I guess it would require at least RCU-level protection of the page->mapping->a_op->isolate_page chain. > For avoiding that, we need another function to peek which just checks > PG_movable bit instead of all things. > > > /* > * If @page_locked is false, we cannot guarantee page->mapping's stability > * so just the function checks with PG_movable which could be false positive > * so caller should check it again under PG_lock to check a_ops->isolate_page. > */ > static inline int PageMovable(struct page *page, bool page_locked) > { > int ret = 0; > struct address_space *mapping; > struct address_space_operations *a_op; > > if (!test_bit(PG_movable, &(page->flags)) > goto out; > > if (!page_locked) { > ret = 1; > goto out; > } > > mapping = page->mapping; > if (!mapping) > goto out; > > a_op = mapping->a_op; > if (!aop) > goto out; > if (a_op->isolate_page) > ret = 1; > out: > return ret; > } I wouldn't put everything into single function, but create something like __PageMovable() just for the unlocked peek. Unlike the zone->lru_lock, we don't keep page_lock() across iterations in isolate_migratepages_block(), as obviously each page has different lock. So the page_locked parameter would be always passed as constant, and at that point it's better to have separate functions. So I guess the question is how many false positives from overlap with PG_reclaim the scanner will hit if we give up on PAGE_MOVABLE_MAPCOUNT_VALUE, as that will increase number of page locks just to realize that it's not actual PageMovable() page... > Thanks for detail review, Vlastimil! > I will resend new versions after vacation in this week. You're welcome, great!